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/.

‌

‌

‌

Building a sidebar from scratch involves much more than an <nav> element. You need collapsible submenus, active state tracking across parent and child items, accessible keyboard navigation, a scroll area for long nav lists, and a consistent design system that holds together across screen sizes.

In this tutorial, you'll learn how to build a fully functional, accessible admin dashboard sidebar using shadcn/ui, a collection of beautifully designed, accessible React components, and a pre-built community block from Shadcn Space, which extends shadcn/ui with ready-to-use dashboard UI patterns.

By the end of this tutorial, you'll have a working sidebar that includes:

• Grouped navigation sections with uppercase labels

• Collapsible parent menu items with child links

• Active state tracking across both parent and child items

• A floating sidebar with an independent scroll area

• A promotional card pinned inside the sidebar footer

Table of Contents

• Prerequisites

• What You Will Build

• Why shadcn/ui?

• What is Shadcn Space?

• How to Install the Sidebar Block

• How to Understand the Folder Structure

• How to Build the Page Layout

• How to Build the AppSidebar Component

• How to Define the Navigation Data

• How to Build the NavMain Component

• How to Handle Active States and Collapsible Menus

• How to Style the Sidebar

• Live Preview

• Summary

Prerequisites

Before you start, make sure you have the following:

• Node.js 18+ installed on your machine

• Basic knowledge of React and TypeScript

• Familiarity with Tailwind CSS utility classes

• A package manager installed (npm, pnpm, yarn, or bun)

You don't need prior experience with shadcn/ui, but it helps to have read through the official docs at least once.

What You Will Build

In this article, you'll build a fully functional admin dashboard sidebar with the following features:

1. Floating sidebar shell: a card-style sidebar with rounded corners, a drop shadow, and a configurable width

2. Grouped navigation: navigation items organized under section labels like Dashboards, Pages, Apps, and Form Elements

3. Collapsible submenus: parent items like Blogs and Shadcn Forms that expand on click to reveal child links

4. Active state tracking: visual highlighting of the selected parent and child item at all times

5. Sidebar toggle: a trigger button in the page header that opens and closes the sidebar

6. Promotional card: a "Get Premium" card at the bottom of the sidebar scroll area

Why shadcn/ui?

shadcn/ui is a collection of beautifully designed, accessible React components built on top of Radix UI and styled with Tailwind CSS.

Instead of installing a traditional component library as a dependency, you copy components directly into your project using a CLI. This gives you full ownership of the code structure and styling. You can read every line, change anything, and the components never break because of a library update you didn't control.

Some key benefits of shadcn/ui include:

• Accessible by default, built on Radix and Base UI primitives

• Fully styled with Tailwind CSS utility classes

• Zero lock-in: the code lives in your project, not inside node_modules

• Works with Next.js, React, Astro, Vite, and other frameworks

• A growing ecosystem of community-built blocks and registries

The Sidebar, Collapsible, ScrollArea, Card, and Button Components you'll use in this tutorial all come from shadcn/ui.

What is Shadcn Space?

Shadcn Space is an open-source library of pre-built UI blocks built on top of shadcn/ui. It provides ready-to-use dashboard layouts, sidebars, tables, cards, and other common admin UI patterns so you don't have to assemble them from individual primitives every time.

Each block in Shadcn Space is installable directly into your project using the shadcn CLI. Once installed, the code is yours: you can read it, extend it, and adapt it to your design system without any runtime dependency on Shadcn Space itself.

For this tutorial, you'll use the sidebar-06 block (it’s free to use), which is a floating admin sidebar with grouped navigation, collapsible submenus, and an integrated scroll area.

Shadcn Space also provides a companion Figma UI Kit that matches the design system used in the blocks, which is useful if you do design work alongside development.

You can explore the full block library and the getting-started documentation in the official Shadcn Space docs.

How to Set Up the Project

Start by creating a new Next.js project if you don't already have one:

npx shadcn@latest init --preset b0 --base base --template next

This command:

• Creates a Next.js project

• Configures Tailwind CSS

• Sets up Base UI as the component foundation

• Uses Nova style preset

• Configures Lucide icons

• Uses Inter font

• Applies neutral theme tokens

Follow the prompts to configure your base color, CSS variables, and component output directory. This sets up the components/ui directory and the required Tailwind configuration that all shadcn/ui components depend on.

Once the initialization is complete, your components.json project will be created at the root of your project. This file tells the shadcn CLI where to place components, what path aliases you're using, and which styling configuration to follow.

Add this in components.json:

{
  "registries": {
    "@shadcn-space": {
      "url": "https://shadcnspace.com/r/{name}.json",
    }
  }
}

How to Install the Sidebar Block

With shadcn/ui initialized, you can now pull in the sidebar-06 block from Shadcn Space. While Shadcn Space provides components for both Radix UI and Base UI, this tutorial uses the Base UI version. Run one of the following commands depending on your package manager:

npm:

npx shadcn@latest add @shadcn-space/sidebar-06

pnpm:

pnpm dlx shadcn@latest add @shadcn-space/sidebar-06

yarn:

yarn dlx shadcn@latest add @shadcn-space/sidebar-06

bun:

bunx --bun shadcn@latest add @shadcn-space/sidebar-06

This command fetches the block from the Shadcn Space registry and scaffolds all the required component files into your project automatically. It also installs any shadcn/ui primitives the block depends on (such as Sidebar, ScrollArea, Card, Button, and Collapsible) if they aren't already present in your components/ui directory.

You can preview the live block and find the installation command on their shadcn sidebar page.

How to Understand the Folder Structure

After installation, your project will contain the following new files:

app/
  sidebar-06/
    page.tsx                  ← Route entry point
assets/
  logo/
    logo.tsx                  ← Logo component
components/
  shadcn-space/
    blocks/
      sidebar-06/
        app-sidebar.tsx       ← Main sidebar shell
        nav-main.tsx          ← Navigation logic and rendering

Each file has a clearly defined responsibility:

• app/sidebar-06/page.tsx: the route entry point that wires the sidebar into a page layout using SidebarProvider

• assets/logo/logo.tsx: the logo component rendered in the sidebar header

• components/shadcn-space/blocks/sidebar-06/app-sidebar.tsx: the main sidebar shell, including the header, scroll area, nav data, and promotional card

• components/shadcn-space/blocks/sidebar-06/nav-main.tsx: all navigation rendering logic, including section labels, leaf items, collapsible parents, and active state management

You'll work through each of these files in detail in the sections below.

How to Build the Page Layout

Open app/sidebar-06/page.tsx. This file is the entry point for your dashboard page. It uses SidebarProvider to establish sidebar context across the page, and SidebarTrigger to render a toggle button inside the header.

import { SidebarProvider, SidebarTrigger } from "@/components/ui/sidebar";
import { AppSidebar } from "@/components/shadcn-space/blocks/sidebar-06/app-sidebar";

const Page = () => {
  return (
    <SidebarProvider
      className="p-4 bg-muted"
      style={{ "--sidebar-width": "300px" } as React.CSSProperties}
    >
      <AppSidebar />

      {/* Main content area */}
      <div className="flex flex-1 flex-col gap-4">
        <header className="flex h-14 shrink-0 items-center gap-2 rounded-xl bg-background px-4 shadow-sm">
          <SidebarTrigger className="cursor-pointer" />
        </header>
        <main className="flex-1 rounded-xl bg-background" />
      </div>
    </SidebarProvider>
  );
};

export default Page;

Let's break down the key parts of this layout:

SidebarProvider wraps everything on the page. It manages the sidebar's open/closed state and passes it down to child components via React context. Any component that needs to read or change the sidebar state, including SidebarTrigger and AppSidebar, must be a descendant of SidebarProvider.

The --sidebar-width CSS custom property controls the rendered width of the sidebar. It's set inline using a type assertion (as React.CSSProperties) because TypeScript doesn't know about this custom property by default. Setting it here rather than in a CSS file keeps the width configurable on a per-page basis.

SidebarTrigger is a toggle button component that reads the sidebar open/closed state from the nearest SidebarProvider context and flips it on click. It renders in the header so users always have access to the toggle regardless of scroll position.

bg-muted on SidebarProvider creates the light gray outer background that makes the floating sidebar card visually stand out from the page.

How to Build the AppSidebar Component

Open components/shadcn-space/blocks/sidebar-06/app-sidebar.tsx. This component is the main sidebar shell. It composes shadcn/ui's Sidebar, SidebarHeader, and SidebarContent layout primitives and wraps the scrollable navigation area in a ScrollArea component to handle overflow independently.

"use client";

import {
  Sidebar,
  SidebarContent,
  SidebarHeader,
  SidebarMenu,
  SidebarMenuItem,
} from "@/components/ui/sidebar";
import { ScrollArea } from "@/components/ui/scroll-area";
import { Card, CardContent } from "@/components/ui/card";
import { Button } from "@/components/ui/button";
import Logo from "@/assets/logo/logo";
import { NavItem, NavMain } from "@/components/shadcn-space/blocks/sidebar-06/nav-main";
import {
  AlignStartVertical,
  PieChart,
  CircleUserRound,
  ClipboardList,
  Notebook,
  NotepadText,
  Table,
  Languages,
  Ticket,
} from "lucide-react";

The "use client" directive at the top is required because this component uses React state (through NavMain) and event handlers, both of which require the component to run in the browser rather than being server-rendered by Next.js.

How to Define the Navigation Data

Inside app-sidebar.tsxthe navigation structure is defined as a flat array of NavItem objects. Each item belongs to one of three categories:

1. A section label marked with isSection: true and a label string. Renders as an uppercase group heading.

2. A leaf item has a title, icon, and href, but no children. Renders as a direct navigation link.

3. A parent item has a title, icon, and a children array of sub-items. Renders as a collapsible trigger.

export const navData: NavItem[] = [
  // Dashboards Section
  { label: "Dashboards", isSection: true },
  { title: "Analytics", icon: PieChart, href: "#" },
  { title: "CRM Dashboard", icon: ClipboardList, href: "#" },

  // Pages Section
  { label: "Pages", isSection: true },
  { title: "Tables", icon: Table, href: "#" },
  { title: "Forms", icon: ClipboardList, href: "#" },
  { title: "User Profile", icon: CircleUserRound, href: "#" },

  // Apps Section
  { label: "Apps", isSection: true },
  { title: "Notes", icon: Notebook, href: "#" },
  { title: "Tickets", icon: Ticket, href: "#" },
  {
    title: "Blogs",
    icon: Languages,
    children: [
      { title: "Blog Post", href: "#" },
      { title: "Blog Detail", href: "#" },
      { title: "Blog Edit", href: "#" },
      { title: "Blog Create", href: "#" },
      { title: "Manage Blogs", href: "#" },
    ],
  },

  // Form Elements Section
  { label: "Form Elements", isSection: true },
  {
    title: "Shadcn Forms",
    icon: NotepadText,
    children: [
      { title: "Button", href: "#" },
      { title: "Input", href: "#" },
      { title: "Select", href: "#" },
      { title: "Checkbox", href: "#" },
      { title: "Radio", href: "#" },
    ],
  },
  {
    title: "Form layouts",
    icon: AlignStartVertical,
    children: [
      { title: "Forms Horizontal", href: "#" },
      { title: "Forms Vertical", href: "#" },
      { title: "Forms Validation", href: "#" },
      { title: "Forms Examples", href: "#" },
      { title: "Forms Wizard", href: "#" },
    ],
  },
];

This flat array approach is intentionally simple to maintain. You don't need a nested tree structure because the NavMain component handles the rendering logic for each item type by inspecting each item's shape. Adding a new section, item, or submenu is as straightforward as appending a new object to the array.

How to Build the NavMain Component

Open components/shadcn-space/blocks/sidebar-06/nav-main.tsx. This file contains all the navigation rendering logic. Start with the type definition and the top-level NavMain function:

"use client";

import * as React from "react";
import { ChevronRight, LucideIcon } from "lucide-react";
import { cn } from "@/lib/utils";
import {
  Collapsible,
  CollapsibleTrigger,
  CollapsibleContent,
} from "@/components/ui/collapsible";
import {
  SidebarGroup,
  SidebarGroupLabel,
  SidebarMenu,
  SidebarMenuButton,
  SidebarMenuItem,
  SidebarMenuSub,
  SidebarMenuSubItem,
  SidebarMenuSubButton,
} from "@/components/ui/sidebar";

export type NavItem = {
  label?: string;
  isSection?: boolean;
  title?: string;
  icon?: LucideIcon;
  href?: string;
  children?: NavItem[];
};

export function NavMain({ items }: { items: NavItem[] }) {
  const [activeParent, setActiveParent] = React.useState<string | null>(
    items.find((i) => !i.isSection)?.title || null
  );
  const [activeChild, setActiveChild] = React.useState<string | null>(null);

  return (
    <>
      {items.map((item, index) => (
        <NavMainItem
          key={item.title || item.label || index}
          item={item}
          activeParent={activeParent}
          setActiveParent={setActiveParent}
          activeChild={activeChild}
          setActiveChild={setActiveChild}
        />
      ))}
    </>
  );
}

activeParent tracks which top-level nav item is currently selected. It initializes to the title of the first non-section item, so the sidebar always has a selection on first render, and you never show the sidebar with nothing highlighted. activeChild tracks which sub-item inside a collapsible menu is selected.

Both state values are passed down as props to each NavMainItem, so every item in the list can read the current selection and trigger updates to it.

How to Handle Active States and Collapsible Menus

The NavMainItem function branches into one of three rendering paths based on the shape of the incoming item.

How to Render Section Labels

if (item.isSection && item.label) {
  return (
    <SidebarGroup className="p-0 pt-5 first:pt-0">
      <SidebarGroupLabel className="p-0 text-xs font-medium uppercase text-sidebar-foreground">
        {item.label}
      </SidebarGroupLabel>
    </SidebarGroup>
  );
}

Section labels use first:pt-0 to remove the top padding from the very first section, so the nav starts flush with the header.

How to Render Collapsible Parent Items

if (hasChildren && item.title) {
  return (
    <SidebarGroup className="p-0">
      <SidebarMenu>
        <Collapsible open={isOpen} onOpenChange={setIsOpen}>
          <SidebarMenuItem>
            <CollapsibleTrigger
              className="w-full"
              render={
                <SidebarMenuButton
                  id={`nav-main-trigger-${item.title.toLowerCase().replace(/\s+/g, '-')}`}
                  tooltip={item.title}
                  isActive={isParentActive}
                  onClick={() => setActiveParent(item.title!)}
                  className={cn(
                    "rounded-md text-sm font-medium px-3 py-2 h-9 transition-colors cursor-pointer",
                    isParentActive ? "bg-primary! text-primary-foreground!" : ""
                  )}
                >
                  {item.icon && <item.icon size={16} />}
                  <span>{item.title}</span>
                  <ChevronRight
                    className={cn(
                      "ml-auto transition-transform duration-200",
                      isOpen && "rotate-90"
                    )}
                  />
                </SidebarMenuButton>
              }
            />
            <CollapsibleContent>
              <SidebarMenuSub className="me-0 pe-0">
                {item.children!.map((child, index) => (
                  <NavMainSubItem
                    key={child.title || index}
                    item={child}
                    activeParent={activeParent}
                    setActiveParent={setActiveParent}
                    activeChild={activeChild}
                    setActiveChild={setActiveChild}
                    parentTitle={item.title}
                  />
                ))}
              </SidebarMenuSub>
            </CollapsibleContent>
          </SidebarMenuItem>
        </Collapsible>
      </SidebarMenu>
    </SidebarGroup>
  );
}

A useEffect inside NavMainItem syncs the local isOpen state with activeParent so that when a different parent is activated, the previously open collapsible stays open until the user explicitly closes it:

React.useEffect(() => {
  if (isParentActive) {
    setIsOpen(true);
  }
}, [isParentActive]);

The ChevronRight icon rotates 90 degrees when the submenu is open, using a Tailwind transition class:

<ChevronRight
  className={cn(
    "ml-auto transition-transform duration-200",
    isOpen && "rotate-90"
  )}
/>

How to Render Leaf Items

if (item.title) {
  return (
    <SidebarGroup className="p-0">
      <SidebarMenu>
        <SidebarMenuItem>
          <SidebarMenuButton
            id={`nav-main-button-${item.title.toLowerCase().replace(/\s+/g, '-')}`}
            tooltip={item.title}
            isActive={isParentActive}
            onClick={() => {
              setActiveParent(item.title!);
              setActiveChild(null);
            }}
            className={cn(
              "rounded-md text-sm font-medium px-3 py-2 h-9 transition-colors cursor-pointer",
              isParentActive ? "bg-primary! text-primary-foreground!" : ""
            )}
            render={<a href={item.href} />}
          >
            {item.icon && <item.icon />}
            {item.title}
          </SidebarMenuButton>
        </SidebarMenuItem>
      </SidebarMenu>
    </SidebarGroup>
  );
}

The render prop on SidebarMenuButton replaces the default button element with an <a> tag. This preserves correct anchor link semantics and accessibility while keeping the button's visual styling. When a leaf item is clicked, activeChild is reset to null since there is no child to track.

How to Render Child Items in a Submenu

The NavMainSubItem function handles sub-items inside a collapsible. When a child is clicked, it sets both activeChild to itself and activeParent to its parent's title so the parent item remains visually highlighted:

if (item.title) {
  return (
    <SidebarMenuSubItem className="w-full">
      <SidebarMenuSubButton
        id={`nav-sub-button-${item.title.toLowerCase().replace(/\s+/g, '-')}`}
        className={cn(
          "w-full rounded-md transition-colors",
          activeChild === item.title ? "bg-muted! text-foreground!" : ""
        )}
        isActive={activeChild === item.title}
        onClick={() => {
          setActiveParent(parentTitle || "");
          setActiveChild(item.title!);
        }}
        render={<a href={item.href}>{item.title}</a>}
      />
    </SidebarMenuSubItem>
  );
}

The child uses a different active style (bg-muted with text-foreground) compared to the parent (bg-primary with text-primary-foreground). This visual distinction makes it easy to see both which section you are in and which specific page is currently active.

Sub-items also support nesting. If a child item itself has a children array, NavMainSubItem renders another Collapsible with a nested SidebarMenuSub, allowing you to build multi-level navigation trees without any changes to the data structure.

How to Style the Sidebar

The full AppSidebar render function puts all of the pieces together:

export function AppSidebar() {
  return (
    <Sidebar variant="floating" className="p-4 h-full [&_[data-slot=sidebar-inner]]:h-full">
      <div className="flex flex-col gap-6 overflow-hidden">

        {/* Header with Logo */}
        <SidebarHeader className="px-4">
          <SidebarMenu>
            <SidebarMenuItem>
              <a href="#" className="w-full h-full">
                <Logo />
              </a>
            </SidebarMenuItem>
          </SidebarMenu>
        </SidebarHeader>

        {/* Scrollable Navigation Content */}
        <SidebarContent className="overflow-hidden">
          <ScrollArea className="h-[calc(100vh-100px)]">
            <div className="px-4">
              <NavMain items={navData} />
            </div>

            {/* Promotional Card */}
            <div className="pt-5 px-4">
              <Card className="shadow-none ring-0 bg-secondary px-4 py-6">
                <CardContent className="p-0 flex flex-col gap-3 items-center">
                  <img
                    src="https://images.shadcnspace.com/assets/backgrounds/download-img.png"
                    alt="sidebar-img"
                    width={74}
                    height={74}
                    className="h-20 w-20"
                  />
                  <div className="flex flex-col gap-4 items-center">
                    <div>
                      <p className="text-base font-semibold text-card-foreground text-center">
                        Grab Pro Now
                      </p>
                      <p className="text-sm font-regular text-muted-foreground text-center">
                        Customize your admin
                      </p>
                    </div>
                    <Button className="w-fit h-9 px-4 py-2 shadow-none cursor-pointer rounded-xl hover:bg-primary/80">
                      Get Premium
                    </Button>
                  </div>
                </CardContent>
              </Card>
            </div>
          </ScrollArea>
        </SidebarContent>

      </div>
    </Sidebar>
  );
}

Let's walk through the key styling decisions:

variant="floating" gives the sidebar a card-like appearance with rounded corners and a subtle drop shadow. It visually lifts the sidebar off the background rather than making it flush with the page edge like a standard sidebar would.

[&_[data-slot=sidebar-inner]]:h-full is an arbitrary Tailwind variant selector that targets shadcn/ui's internal sidebar slot element. Without this, the sidebar inner container doesn't fill the full available height, which breaks the layout. The data-slot attribute is how shadcn/ui identifies internal sub-elements of compound components.

h-[calc(100vh-100px)] on ScrollArea makes the navigation list independently scrollable. The 100px offset accounts for the sidebar header and padding, so the scroll area doesn't overflow the viewport. The rest of the page layout remains static while the nav scrolls.

The bg-secondary card at the bottom of the scroll area is a common admin dashboard pattern, a soft prompt for an upgrade or onboarding action that lives passively in the sidebar without blocking navigation.

For more details on the Sidebar component's API, variants, and configuration options, refer to the official shadcn/ui sidebar docs.

Live Preview

Summary

Congratulations! You have now built a complete, production-ready admin dashboard sidebar using shadcn/ui and a community block from Shadcn Space.

Here is a recap of everything you covered:

• Setting up a Next.js project with shadcn/ui initialized and a pre-built sidebar block installed from Shadcn Space

• Using SidebarProvider and SidebarTrigger to manage the sidebar open/closed state across a page layout through React context

• Defining navigation data as a flat array of typed NavItem objects covering section labels, leaf items, and collapsible parent items

• Rendering all three item types from a single navData source in the NavMain and NavMainItem components

• Tracking activeParent and activeChild state in a single location and passing them as props so every item can read and update the shared selection state

• Using Collapsible with a useEffect sync to keep parent items open when they are active, and animate the chevron icon on expand and collapse

• Applying the floating variant, an arbitrary Tailwind slot selector, and ScrollArea with a calculated height to produce a polished, production-appropriate sidebar layout

This pattern scales well beyond what you built here. You can extend NavItem with additional fields like badge counts, permission flags, or external link indicators. You can swap in real href values and connect activeParent and activeChild to your router so the selection always reflects the current URL. You can also add more sections to navData without touching any rendering logic.

For a quick checkout, we have used the Shadcn Space free Shadcn dashboard block in this dashboard shell.

If you want to explore more pre-built admin UI blocks, components, and templates built on top of shadcn/ui, you can browse the full library at Shadcn Space.

Resources

• Shadcn UI Blocks

• Shadcn UI Components

• Shadcn Space Getting Started Docs

• Figma UI Kit Design System

• shadcn/ui Sidebar Docs

• Base UI

By combining semantic HTML, responsive design techniques, and accessibility best practices (like ARIA roles and keyboard navigation), developers can create interfaces that work across devices and for all users, including those with disabilities.

This article shows how to design scalable, inclusive React UIs using real-world patterns and code examples.

Table of Contents

• Prerequisites

• Overview

• Why Accessibility and Responsiveness Matter

• Core Principles of Accessible and Responsive Design

• Using Semantic HTML in React

• Structuring a Page with Semantic Elements

• Building Responsive Layouts

• Accessibility with ARIA

• Keyboard Navigation

• Focus Management

• Forms and Accessibility

• Responsive Typography and Images

• Building a Fully Accessible Responsive Component (End-to-End Example)

• Testing Accessibility

• Best Practices

• When NOT to Overuse Accessibility Features

• Future Enhancements

• Conclusion

Prerequisites

Before following along, you should be familiar with:

• React fundamentals (components, hooks, JSX)

• Basic HTML and CSS

• JavaScript ES6 features

• Basic understanding of accessibility concepts (helpful but not required)

Overview

Modern web applications must serve a diverse audience across a wide range of devices, screen sizes, and accessibility needs. Users today expect seamless experiences whether they are browsing on a desktop, tablet, or mobile device – and they also expect interfaces that are usable regardless of physical or cognitive limitations.

Two essential principles help achieve this:

• Responsive design, which ensures layouts adapt to different screen sizes

• Accessibility, which ensures applications are usable by people with disabilities

In React applications, these principles are often implemented incorrectly or treated as afterthoughts. Developers may rely heavily on div-based layouts, ignore semantic HTML, or overlook accessibility features such as keyboard navigation and screen reader support.

This article will show you how to build responsive and accessible UI designs in React using semantic HTML. You'll learn how to:

• Structure components using semantic HTML elements

• Build responsive layouts using modern CSS techniques

• Improve accessibility with ARIA attributes and proper roles

• Ensure keyboard navigation and screen reader compatibility

• Apply best practices for scalable and inclusive UI design

By the end of this guide, you'll be able to create React interfaces that are not only visually responsive but also accessible to all users.

Why Accessibility and Responsiveness Matter

Responsive and accessible design isn't just about compliance. It directly impacts usability, performance, and reach.

Accessibility benefits:

• Supports users with visual, motor, or cognitive impairments

• Improves SEO and content discoverability

• Enhances usability for all users

Responsiveness benefits:

• Ensures consistent UX across devices

• Reduces bounce rates on mobile

• Improves performance and scalability

Ignoring these principles can result in broken layouts on smaller screens, poor screen reader compatibility, and limited reach and usability.

Core Principles of Accessible and Responsive Design

Before diving into the code, it’s important to understand the foundational principles.

1. Semantic HTML First

Semantic HTML refers to using HTML elements that clearly describe their meaning and role in the interface, rather than relying on generic containers like <div> or <span>.These elements provide built-in accessibility, improve SEO, and make code more readable.

For example:

Non-semantic:

<div onClick={handleClick}>Submit</div>

Semantic:

<button type="button" onClick={handleClick}>Submit</button>

Another example:

Non-semantic:

<div className="header">My App</div>

Semantic:

<header>My App</header>

Using semantic elements such as <header>, <nav>, <main>, <section>, <article>, and <button> helps browsers and assistive technologies (like screen readers) understand the structure and purpose of your UI without additional configuration.

Why this matters:

• Screen readers understand semantic elements automatically

• It supports built-in accessibility (keyboard, focus, roles)

• There's less need for ARIA attributes

• It gives you better SEO and maintainability

2. Mobile-First Design

Mobile-first design means starting your UI design with the smallest screen sizes (typically mobile devices) and progressively enhancing the layout for larger screens such as tablets and desktops.

This approach makes sure that core content and functionality are prioritized, layouts remain simple and performant, and users on mobile devices get a fully usable experience.

In practice, mobile-first design involves:

• Using a single-column layout initially

• Applying minimal styling and spacing

• Avoiding complex UI patterns on small screens

Then, you scale up using CSS media queries:

.container {
  display: flex;
  flex-direction: column;
}
@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

Here, the default layout is optimized for mobile, and enhancements are applied only when the screen size increases.

Why this approach works:

• Prioritizes essential content

• Improves performance on mobile devices

• Reduces layout bugs when scaling up

• Aligns with how most users access web apps today

3. Progressive Enhancement

Progressive enhancement is the practice of building a baseline user experience that works for all users (regardless of their device, browser capabilities, or network conditions) and then layering on advanced features for more capable environments.

This approach ensures that core functionality is always accessible, users on older devices or slow networks aren't blocked, and accessibility is preserved even when advanced features fail.

In practice, this means:

• Start with semantic HTML that delivers content and functionality

• Add basic styling with CSS for layout and readability

• Enhance interactivity using JavaScript (React) only where needed

For example, a form should still be usable with plain HTML:

<form>
  <label htmlFor="email">Email</label>
  <input id="email" type="email" />
  <button type="submit">Submit</button>
</form>

Then, React can enhance it with validation, dynamic feedback, or animations.

By prioritizing functionality first and enhancements later, you ensure your application remains usable in a wide range of real-world scenarios.

4. Keyboard Accessibility

Keyboard accessibility ensures that users can navigate and interact with your application using only a keyboard. This is critical for users with motor disabilities and also improves usability for power users.

Key aspects of keyboard accessibility include:

• Ensuring all interactive elements (buttons, links, inputs) are focusable

• Maintaining a logical tab order across the page

• Providing visible focus indicators (for example, outline styles)

• Supporting keyboard events such as Enter and Space

Bad Example (Not Accessible)

<div onClick={handleClick}>Submit</div>

This element:

• Cannot be focused with a keyboard

• Does not respond to Enter/Space

• Is invisible to screen readers

Good Example

<button type="button" onClick={handleClick}>Submit</button>

This automatically supports:

• Keyboard interaction

• Focus management

• Screen reader announcements

Custom Component Example (if needed)

<div
  role="button"
  tabIndex={0}
  onClick={handleClick}
  onKeyDown={(e) => {
    if (e.key === 'Enter' || e.key === ' ') {
      e.preventDefault();
      handleClick();
    }
  }}
>
  Submit
</div>

But only use this when native elements aren't sufficient.

These principles form the foundation of accessible and responsive design:

• Use semantic HTML to communicate intent

• Design for mobile first, then scale up

• Enhance progressively for better compatibility

• Ensure full keyboard accessibility

Applying these early prevents major usability and accessibility issues later in development.

Using Semantic HTML in React

As we briefly discussed above, semantic HTML plays a critical role in both accessibility (a11y) and code readability. Semantic elements clearly describe their purpose to both developers and browsers, which allows assistive technologies like screen readers to interpret and navigate the UI correctly.

For example, when you use a <button> element, browsers automatically provide keyboard support, focus behavior, and accessibility roles. In contrast, non-semantic elements like <div>require additional attributes and manual handling to achieve the same functionality.

From a readability perspective, semantic HTML makes your code easier to understand and maintain. Developers can quickly identify the structure and intent of a component without relying on class names or external documentation.

Bad Example (Non-semantic)

<div onClick={handleClick}>Submit</div>

Why this is problematic:

• The <div>element has no inherent meaning or role

• It is not focusable by default, so keyboard users can't access it

• It does not respond to keyboard events like Enter or Space unless explicitly coded

• Screen readers do not recognize it as an interactive element

To make this accessible, you would need to add:

role="button"

tabIndex="0"

Keyboard event handlers

Good Example (Semantic)

<button type="button" onClick={handleClick}>Submit</button>

Why this is better:

• The <button> element is inherently interactive

• It is automatically focusable and keyboard accessible

• It supports Enter and Space key activation by default

• Screen readers correctly announce it as a button

This reduces complexity while improving accessibility and usability.

Why all this matters:

There are many reasons to use semantic HTML.

First, semantic elements like <button>, <a>, and <form> come with default accessibility behaviors such as focus management and keyboard interaction

It also reduces complexity: you don’t need to manually implement roles, keyboard handlers, or tab navigation

They provide better screen reader support as well. Assistive technologies can correctly interpret the purpose of elements and announce them appropriately

Semantic HTML also improves maintainability and helps other developers quickly understand the intent of your code without reverse-engineering behavior from event handlers

Finally, you'll generally have fewer bugs in your code. Relying on native browser behavior reduces the risk of missing critical accessibility features

Here's another example:

Non-semantic:

<div className="nav">
  <div onClick={goHome}>Home</div>
</div>

Semantic:

<nav>
  <a href="/">Home</a>
</nav>

Here, <nav> clearly defines a navigation region, and <a> provides built-in link behavior, including keyboard navigation and proper screen reader announcements.

Structuring a Page with Semantic Elements

When building a React application, structuring your layout with semantic HTML elements helps define clear regions of your interface. Instead of relying on generic containers like <div>, semantic elements communicate the purpose of each section to both developers and assistive technologies.

In the example below, we're creating a basic page layout using commonly used semantic elements such as <header>, <nav>, <main>, <section>, and <footer>. Each of these elements represents a specific part of the UI and contributes to better accessibility and maintainability.

function Layout() {
  return (
    <>
      {/* Skip link for keyboard and screen reader users */}
      <a href="#main-content" className="skip-link">
        Skip to main content
      </a>

      <header>
        <h1>My App</h1>
      </header>

      <nav>
        <ul>
          <li><a href="/">Home</a></li>
        </ul>
      </nav>

      <main id="main-content">
        <section>
          <h2>Dashboard</h2>
        </section>
      </main>

      <footer>
        <p>© 2026</p>
      </footer>
    </>
  );
}

Each element in this layout has a specific role:

• The skip link allows screen reader users to skip to the main content

• <header>: Represents introductory content or branding

• <nav>: Contains navigation links

• <main>: Holds the primary content of the page

• <section>: Groups related content within the page

• <footer>: Contains closing or supplementary information

Using these elements correctly ensures your UI is both logically structured and accessible by default.

Why this structure is important:

Properly structuring a page like this brings with it many benefits.

For example, it gives you Improved screen reader navigation. This is because semantic elements allow screen readers to identify different regions of the page (for example, navigation, main content, footer). Users can quickly jump between these sections instead of reading the page linearly

It also gives you better document structure. Elements like <main> and <section> define a logical hierarchy, making content easier to parse for both browsers and assistive technologies

Search engines also use semantic structure to better understand page content and prioritize important sections, resulting in better SEO.

It also makes your code more readable, so other devs can immediately understand the layout and purpose of each section without relying on class names or comments

And it provides built-in accessibility landmarks using elements like <nav> and <main>, allowing assistive technologies to provide shortcuts for users.

Building Responsive Layouts

Responsive layouts ensure that your UI adapts smoothly across different screen sizes, from mobile devices to large desktop displays. Instead of building separate layouts for each device, modern CSS techniques like Flexbox, Grid, and media queries allow you to create flexible, fluid designs.

In this section, we’ll look at how layout behavior changes based on screen size, starting with a mobile-first approach and progressively enhancing the layout for larger screens.

Using CSS Flexbox:

.container {
  display: flex;
  flex-direction: column;
}

@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

On smaller screens (mobile), elements are stacked vertically using flex-direction: column, making content easier to read and scroll.

On larger screens (768px and above), the layout switches to a horizontal row, utilizing available screen space more efficiently.

Why this helps:

• Ensures content is readable on small devices without horizontal scrolling

• Improves layout efficiency on larger screens

• Supports a mobile-first design strategy by defining the default layout for smaller screens first and enhancing it progressively

Using CSS Grid:

.grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 16px;
}

@media (min-width: 768px) {
  .grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

On mobile devices, content is displayed in a single-column layout (1fr), ensuring each item takes full width.

On larger screens, the layout shifts to three equal columns using repeat(3, 1fr), creating a grid structure.

Why this helps:

• Provides a clean and consistent way to manage complex layouts

• Makes it easy to scale from simple to multi-column designs

• Improves visual balance and spacing across different screen sizes

React Example:

function CardGrid() {
  return (
    <div className="grid">
      <div className="card">Item 1</div>
      <div className="card">Item 2</div>
      <div className="card">Item 3</div>
    </div>
  );
}

The React component uses the .grid class to apply responsive Grid behavior. Each card automatically adjusts its position based on screen size.

Why this is effective:

• Separates structure (React JSX) from layout (CSS)

• Allows you to reuse the same component across different screen sizes without modification

• Ensures consistent responsiveness across your application with minimal code

By combining Flexbox for one-dimensional layouts and Grid for two-dimensional layouts, you can build highly adaptable interfaces that respond efficiently to different devices and screen sizes.

Accessibility with ARIA

ARIA (Accessible Rich Internet Applications) is a set of attributes that enhance the accessibility of web content, especially when building custom UI components that cannot be fully implemented using native HTML elements.

ARIA works by providing additional semantic information to assistive technologies such as screen readers. It does this through:

• Roles, which define what an element is (for example, button, dialog, menu)

• States and properties, which describe the current condition or behavior of an element (for example, expanded, hidden, live updates)

For example, when you create a custom dropdown using <div> elements, browsers don't inherently understand its purpose. By applying ARIA roles and attributes, you can communicate that this structure behaves like a menu and ensure it is interpreted correctly.

Just make sure you use ARIA carefully. Incorrect or unnecessary usage can reduce accessibility. Here's a key rule to follow: use native HTML first. Only use ARIA when necessary.

ARIA is especially useful for:

• Custom UI components (modals, tabs, dropdowns)

• Dynamic content updates

• Complex interactions not covered by standard HTML

Something to note before we get into the examples here: real-world accessibility is complex. For production apps, you should typically prefer well-tested libraries like react-aria, Radix UI, or Headless UI. These examples are primarily for educational purposes and aren't production-ready.

Example: Accessible Modal

function Modal({ isOpen, onClose }) {
  const dialogRef = React.useRef();

  React.useEffect(() => {
    if (isOpen) {
      dialogRef.current?.focus();
    }
  }, [isOpen]);

  if (!isOpen) return null;

  return (
    <div
      role="dialog"
      aria-modal="true"
      aria-labelledby="modal-title"
      tabIndex={-1}
      ref={dialogRef}
      onKeyDown={(e) => {
        if (e.key === 'Escape') onClose();
      }}
    >
      <h2 id="modal-title">Modal Title</h2>
      <button type="button" onClick={onClose}>Close</button>
    </div>
  );
}

How this works:

• role="dialog" identifies the element as a modal dialog

• aria-modal="true" indicates that background content is inactive

• aria-labelledby connects the dialog to its visible title for screen readers

• tabIndex={-1} allows the dialog container to receive focus programmatically

• Focus is moved to the dialog when it opens

• Pressing Escape closes the modal, which is a standard accessibility expectation

This ensures that users can understand, navigate, and exit the modal using both keyboard and assistive technologies.

Key ARIA Attributes

1. role

Defines the type of element and its purpose. For example, role="dialog" tells assistive technologies that the element behaves like a modal dialog.

2. aria-label

Provides an accessible name for an element when visible text is not sufficient. Screen readers use this label to describe the element to users.

3. aria-hidden

Indicates whether an element should be ignored by assistive technologies. For example, aria-hidden="true" hides decorative elements from screen readers.

4. aria-live

Used for dynamic content updates. It tells screen readers to announce changes automatically without requiring user interaction (for example, form validation messages or notifications).

Example: Accessible Dropdown (Custom Component)

function Dropdown({ isOpen, toggle }) {
  return (
    <div>
      <button
        type="button"
        aria-expanded={isOpen}
        aria-controls="dropdown-menu"
        onClick={toggle}
      >
        Menu
      </button>

      {isOpen && (
        <ul id="dropdown-menu">
          <li>
            <button type="button" onClick={() => console.log('Item 1')}>
              Item 1
            </button>
          </li>
          <li>
            <button type="button" onClick={() => console.log('Item 2')}>
              Item 2
            </button>
          </li>
        </ul>
      )}
    </div>
  );
}

How this works:

• aria-expanded indicates whether the dropdown is open or closed

• aria-controls links the button to the dropdown content via its id

• The <button> element acts as the trigger and is fully keyboard accessible

• The <ul> and <li> elements provide a natural list structure

• Using <a> elements ensures proper navigation behavior and accessibility

Why this approach is correct:

• It follows standard web patterns instead of application-style menus

• It avoids misusing ARIA roles like role="menu", which require complex keyboard handling

• Screen readers can correctly interpret the structure without additional roles

• It keeps the implementation simple, accessible, and maintainable

If you need advanced menu behavior (like arrow key navigation), then ARIA menu roles may be appropriate – but only when fully implemented according to the ARIA Authoring Practices.

Note: Most dropdowns in web applications are not true "menus" in the ARIA sense. Avoid using role="menu" unless you are implementing full keyboard navigation (arrow keys, focus management, and so on).

Keyboard Navigation

Keyboard navigation ensures that users can fully interact with your application using only a keyboard, without relying on a mouse. This is essential for users with motor disabilities, but it also benefits power users and developers who prefer keyboard-based workflows.

In a well-designed interface, users should be able to:

• Navigate through interactive elements using the Tab key

• Activate buttons and links using Enter or Space

• Clearly see which element is currently focused

In the example below, we’ll look at common mistakes in keyboard handling and why relying on native HTML elements is usually the better approach.

Example:

Avoid adding custom keyboard handlers to native elements like <button>, as they already support keyboard interaction by default.

For example, this is all you need:

<button type="button" onClick={handleClick}>Submit</button>

This automatically supports:

• Enter and Space key activation

• Focus management

• Screen reader announcements

Adding manual keyboard event handlers here is unnecessary and can introduce bugs or inconsistent behavior.

What this example shows:

Avoid manually handling keyboard events for native interactive elements like <button>. These elements already provide built-in keyboard support and accessibility features.

For example:

<button type="button" onClick={handleClick}>Submit</button>

Why this works:

• Supports both Enter and Space key activation by default

• Is focusable and participates in natural tab order

• Provides built-in accessibility roles and screen reader announcements

• Reduces the need for additional logic or ARIA attributes

Adding custom keyboard handlers (like onKeyDown) to native elements is unnecessary and can introduce bugs or inconsistent behavior. Always prefer native HTML elements for interactivity whenever possible.

Avoiding Common Keyboard Traps

One of the most common keyboard accessibility issues is “trapping users inside interactive components”, such as modals or custom dropdowns. This happens when focus is moved into a component but can't escape using Tab, Shift+Tab, or other keyboard controls. Users relying on keyboards may become stuck, unable to navigate to other parts of the page.

In the example below, you'll see a simple modal that tries to set focus, but doesn’t manage Tab behavior properly.

function Modal({ isOpen }) {
  const ref = React.useRef();

  React.useEffect(() => {
    if (isOpen) ref.current?.focus();
  }, [isOpen]);

  return (
    <div role="dialog">
      <button type="button" ref={ref}>Close</button>
    </div>
  );
}

What this code shows:

• When the modal opens, focus is moved to the Close button using ref.current.focus()

• The modal uses role="dialog" to communicate its purpose

There are some issues with this code that you should be aware of. First, tabbing inside the modal may allow focus to move outside the modal if additional focusable elements exist.

Users may also become trapped if no mechanism returns focus to the triggering element when the modal closes.

There's also no handling of Shift+Tab or cycling focus is present.

This demonstrates a partial focus management, but it’s not fully accessible yet.

To improve focus management, you can trap focus within the modal by ensuring that Tab and Shift+Tab cycle only through elements inside the modal.

You can also return focus to the trigger: when the modal closes, return focus to the element that opened it.

Example improvement (conceptual):

function Modal({ isOpen, onClose, triggerRef }) {
  const modalRef = React.useRef();

  React.useEffect(() => {
    if (isOpen) {
      modalref.current?.focus();
      // Add focus trap logic here
    } else {
      triggerref.current?.focus();
    }
  }, [isOpen]);

  return (
    <div role="dialog" ref={modalRef} tabIndex={-1}>
      <button type="button" onClick={onClose}>Close</button>
    </div>
  );
}

Remember that this modal is not fully accessible without focus trapping. In production, use a library like focus-trap-react, react-aria, or Radix UI.

Key points:

• tabIndex={-1} allows the div to receive programmatic focus

• Focus trap ensures users cannot tab out unintentionally

• Returning focus preserves context, so users can continue where they left off

Best practices:

• Always move focus into modals

• Return focus to the trigger element when closed

• Ensure Tab cycles correctly

As a general rule, always prefer native HTML elements for interactivity. Only implement custom keyboard handling when building advanced components that cannot be achieved with standard elements.

Focus Management

Focus management is the practice of controlling where keyboard focus goes when users interact with components such as modals, forms, or interactive widgets. Proper focus management ensures that:

• Users relying on keyboards or assistive technologies can navigate seamlessly

• Focus does not get lost or trapped in unexpected places

• Users maintain context when content updates dynamically

The example below shows a common approach that only partially handles focus:

Bad Example:

// Bad Example: Automatically focusing input without context
const ref = React.useRef();
React.useEffect(() => {
  ref.current?.focus();
}, []);
<input ref={ref} placeholder="Name" />

In the above code, the input receives focus as soon as the component mounts, but there’s no handling for returning focus when the user navigates away.

If this input is inside a modal or dynamic content, users may get lost or trapped. There aren't any focus indicators or context for assistive technologies.

This is a minimal solution that can cause confusion in real applications.

Improved Example:

// Improved Example: Managing focus in a modal context
function Modal({ isOpen, onClose, triggerRef }) {  
const dialogRef = React.useRef();

  React.useEffect(() => {
    if (isOpen) {
      dialogRef.current?.focus();
    } else if (triggerRef?.current) {
      triggerref.current?.focus();
    }
  }, [isOpen]);

  React.useEffect(() => {
    function handleKeyDown(e) {
      if (e.key === 'Escape') {
        onClose();
      }
    }

    if (isOpen) {
      document.addEventListener('keydown', handleKeyDown);
    }

    return () => {
      document.removeEventListener('keydown', handleKeyDown);
    };
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return (
    <div
      role="dialog"
      aria-modal="true"
      aria-labelledby="modal-title"
      tabIndex={-1}
      ref={dialogRef}
    >
      <h2 id="modal-title">Modal Title</h2>
      <button type="button" onClick={onClose}>Close</button>
      <input type="text" placeholder="Name" />
    </div>
  );
}

Explanation:

• tabIndex={-1} enables the dialog container to receive focus

• Focus is moved to the modal when it opens, ensuring keyboard users start in the correct context

• Focus is returned to the trigger element when the modal closes, preserving user flow

• aria-labelledby provides an accessible name for the dialog

• Escape key handling allows users to close the modal without a mouse

Note: For full accessibility, you should also implement focus trapping so users cannot tab outside the modal while it is open.

Tip: In production applications, use libraries like react-aria, focus-trap-react, or Radix UI to handle focus trapping and accessibility edge cases reliably.

Also, keep in mind here that the document-level keydown listener is global, which affects the entire page and can conflict with other components.

document.addEventListener('keydown', handleKeyDown);

A safer alternative is to scope it to the modal:

<div
  onKeyDown={(e) => {
    if (e.key === 'Escape') onClose();
  }}
>

For simple cases, attach onKeyDown to the dialog instead of the document.

Best Practice:

For complex components, use libraries like focus-trap-react or react-aria to manage focus reliably, especially for modals, dropdowns, and popovers.

Forms and Accessibility

Forms are critical points of interaction in web applications, and proper accessibility ensures that all users – including those using screen readers or other assistive technologies – can understand and interact with them effectively.

Proper labeling means that every input field, checkbox, radio button, or select element has an associated label that clearly describes its purpose. This allows screen readers to announce the input meaningfully and helps keyboard-only users understand what information is expected.

In addition to labeling, form accessibility includes:

• Providing clear error messages when input is invalid

• Ensuring error messages are announced to assistive technologies

• Maintaining logical focus order so users can navigate inputs easily

Bad Example:

<input type="text" placeholder="Name" />

Why this isn't good:

• This input relies only on a placeholder for context

• Screen readers may not announce the purpose of the field clearly

• Once a user starts typing, the placeholder disappears, leaving no guidance

• Keyboard-only users may not have enough context to know what to enter

Good Example:

<label htmlFor="name">Name</label>
<input id="name" type="text" />

Why this is better:

• The <label> is explicitly associated with the input via htmlFor / id

• Screen readers announce "Name" before the input, providing clear context

• Users navigating with Tab understand the field’s purpose

• The label persists even when the user types, unlike a placeholder

Error Handling:

<label htmlFor="name">Name</label>
<input
  id="name"
  type="text"
  aria-describedby="name-error"
  aria-invalid="true"
/>

<p id="name-error" role="alert">
  Name is required
</p>

Explanation

• aria-describedby links the input to the error message using the element’s id

• Screen readers announce the error message when the input is focused

• aria-invalid="true" indicates that the field currently contains an error

• role="alert" ensures the error message is announced immediately when it appears

This creates a clear relationship between the input and its validation message, improving usability for screen reader users.

Tip: Only apply aria-invalid and error messages when validation fails. Avoid marking fields as invalid before user interaction.

Responsive Typography and Images

Responsive typography and images ensure that your content remains readable and visually appealing across a wide range of devices, from small smartphones to large desktop monitors.

This is important, because text should scale naturally so it remains legible on all screens, and images should adjust to container sizes to avoid layout issues or overflow. Both contribute to a better user experience and accessibility

In this section, we’ll cover practical ways to implement responsive typography and images in React and CSS.

h1 {
  font-size: clamp(1.5rem, 2vw, 3rem);
}

In this code:

• The clamp() function allows text to scale fluidly:

• The first value (1.5rem) is the “minimum font size”

• The second value (2vw) is the “preferred size based on viewport width”

• The third value (3rem) is the “maximum font size”

• This ensures headings are “readable on small screens” without becoming too large on desktops

Alternative methods include using media queries to adjust font sizes at different breakpoints

Responsive Images:

<img src="image.jpg" alt="Description" loading="lazy" />

In this code, responsive images adapt to different screen sizes and resolutions to prevent layout issues or slow loading times. Key techniques include:

1. Fluid images using CSS:

img {
     max-width: 100%;
     height: auto;
   }

This makes sure that images never overflow their container and maintains aspect ratio automatically.

2. Using srcset for multiple resolutions:

<img src="image-small.jpg"
     srcset="image-small.jpg 480w,
             image-medium.jpg 1024w,
             image-large.jpg 1920w"
     sizes="(max-width: 600px) 480px,
            (max-width: 1200px) 1024px,
            1920px"
     alt="Description">

This provides different image files depending on screen size or resolution and reduces loading times and improves performance on smaller devices.

3. Always include descriptive alt text

This is critical for screen readers and accessibility. It also helps users understand the image if it cannot be loaded.

Tip: Combine responsive typography, images, and flexible layout containers (like CSS Grid or Flexbox) to create interfaces that scale gracefully across all devices and maintain accessibility.

4. Ensure Sufficient Color Contrast

Low contrast text can make content unreadable for many users.

.bad-text {
  color: #aaa;
}

.good-text {
  color: #222;
}

Use tools like WebAIM Contrast Checker and Chrome DevTools Accessibility panel to check your color contrasts. Also note that WCAG AA requires 4.5:1 contrast ratio for normal text.

Building a Fully Accessible Responsive Component (End-to-End Example)

To understand how responsiveness and accessibility work together in practice, let’s build a reusable accessible card component that adapts to screen size and supports keyboard and screen reader users.

Step 1: Component Structure (Semantic HTML)

function ProductCard({ title, description, onAction }) {
  return (
    <article className="card">
      <h3>{title}</h3>
      <p>{description}</p>
      <button type="button" onClick={onAction}>
        View Details
      </button>
    </article>
  );
}

Why This Works

• <article> provides semantic meaning for standalone content

• <h3> establishes a proper heading hierarchy

• <button> ensures built-in keyboard and accessibility support

Step 2: Responsive Styling

.card {
  padding: 16px;
  border: 1px solid #ddd;
  border-radius: 8px;
}

@media (min-width: 768px) {
  .card {
    padding: 24px;
  }
}

This ensures comfortable spacing on mobile and improved readability on larger screens.

Step 3: Accessibility Enhancements

<button type="button" onClick={onAction}>
  View Details
</button>

The visible button text provides a clear and accessible label, so no additional ARIA attributes are needed.

Step 4: Keyboard Focus Styling

button:focus {
  outline: 2px solid blue;
  outline-offset: 2px;
}

Focus indicators are essential for keyboard users.

Step 5: Using the Component

function App() {
  return (
    <div className="grid">
      <ProductCard
        title="Product 1"
        description="Accessible and responsive"
        onAction={() => alert('Clicked')}
      />
    </div>
  );
}

Key Takeaways

This simple component demonstrates:

• Semantic HTML structure

• Responsive design

• Built-in accessibility via native elements

• Minimal ARIA usage

In real-world applications, this pattern scales into entire design systems.

Testing Accessibility

Accessibility should be validated continuously, not just at the end of development. There are various automated tools you can use to help you with this process:

• Lighthouse (built into Chrome DevTools)

• axe DevTools for detailed audits

• ESLint plugins for accessibility rules

Manual Testing

But automated tools cannot catch everything. Manual testing is essential to make sure users can navigate using only the keyboard and use a screen reader (NVDA or VoiceOver. You should also test zoom levels (up to 200%) and check the color contrast manually.

Example: ESLint Accessibility Plugin

npm install eslint-plugin-jsx-a11y --save-dev

This helps catch accessibility issues during development.

Best Practices

• Use semantic HTML first

• Avoid unnecessary ARIA

• Test keyboard navigation

• Design mobile-first

• Ensure color contrast

• Use consistent spacing

When NOT to Overuse Accessibility Features

• Avoid adding ARIA when native HTML works

• Do not override browser defaults unnecessarily

• Avoid complex custom components without accessibility support

Future Enhancements

• Design systems with accessibility built-in

• Automated accessibility testing in CI/CD

• Advanced focus management libraries

• Accessibility-first component libraries

Conclusion

Building responsive and accessible React applications is not a one-time effort—it is a continuous design and engineering practice. Instead of treating accessibility as a checklist, developers should integrate it into the core of their component design process.

If you are starting out, focus on using semantic HTML and mobile-first layouts. These two practices alone solve a large percentage of accessibility and responsiveness issues. As your application grows, introduce ARIA enhancements, keyboard navigation, and automated accessibility testing.

The key is to build interfaces that work for everyone by default. When responsiveness and accessibility are treated as first-class concerns, your React applications become more usable, scalable, and future-proof.

A basic tab switcher can show and hide content. A better one gives users a clear active state, smooth transitions, and a little bit of motion that makes the interface feel alive. That's the idea behind this component: a reusable animated tab system built in the Shadcn style, with React, Tailwind CSS, and Motion.

In this tutorial, you’ll build exactly that: a fully animated tab component built by Shadcn/ui, Framer Motion, and a ready-to-use registry component from Shadcn Space.

By the end, you’ll have a reusable <Tabs/> component with:

• A spring-animated active pill indicator

• A stacked card effect that fans out on hover

• A smooth entrance animation when the active tab changes

• Fully theme-aware styling using Shadcn/ui CSS variables

Video walkthrough: If you prefer to follow along visually, watch the full tutorial on YouTube:

Table of Contents

• Prerequisites

• What You’ll Build

• Install the Component via Shadcn Space CLI

• Understand the Component Structure

• Step 1 - Define the Tab Data Types

• Step 2 - Build the Tab Data Array

• Step 3 - Build the Tabs Component (Tab Bar + State)

• Step 4 - Build the FadeInStack Component

• Step 5 - Compose the Page Component

• Step 6 - Customize the Component

• Live Preview

• Key Concepts Recap

• Conclusion

• Resources

Prerequisites

Before you begin, make sure you have a working knowledge of:

• React and TypeScript basics

• Tailwind CSS utility classes

• The basics of Shadcn/ui (component installation and theming)

You’ll also need a Next.js or Vite project with the following already set up:

• Shadcn/ui installed and initialized

• Framer Motion (also referred to as motion/react) installed

What You’ll Build

Here’s an overview of the component architecture you’ll create in this tutorial:

AnimatedTabMotion (page/demo entry point)
└── Tabs (tab bar + content orchestrator)
├── Tab buttons (with spring-animated active pill)
└── FadeInStack (stacked, animated content panels)

The key behaviors are:

1. Spring pill animation – A spring pill animation is a UI effect in which the active tab indicator, a rounded, pill-shaped highlight, physically moves from one button to another using a spring physics curve rather than a standard CSS transition. Instead of teleporting or fading, the pill slides between tabs with a subtle bounce at the end, mimicking the momentum of a real physical object.

2. Stacked card effect – inactive tab panels are rendered behind the active one, scaled down and slightly faded, giving a layered depth illusion.

3. Fan-out on hover – when the user hovers over the content area, the stacked cards spread out vertically.

4. Bounce entrance – the top (active) card animates downward and back into place when a new tab is selected.

Install the Component via Shadcn Space CLI

Shadcn Space is a registry of production-ready Shadcn/ui-compatible components. Instead of scaffolding this component from scratch, you can pull it directly into your project using the Shadcn CLI.

Check out their Getting Started guide to learn how to use the Shadcn CLI with third-party registries.

Run one of the following commands, depending on your package manager:

pnpm

pnpm dlx shadcn@latest add @shadcn-space/tabs-01

npm

npx shadcn@latest add @shadcn-space/tabs-01

Yarn

yarn dlx shadcn@latest add @shadcn-space/tabs-01

Bun

bunx --bun shadcn@latest add @shadcn-space/tabs-01

This scaffolds the component file into your project, pre-wired to your existing Shadcn/ui theme tokens. You can then customize or extend it as needed, which is exactly what you’ll learn in this tutorial.

Understand the Component Structure

Before writing any code, let’s review the full component and break it into logical pieces. Here is the complete implementation:

"use client";

import { useState } from "react";
import { motion } from "motion/react";
import { cn } from "@/lib/utils";

type Tab = {
  title: string;
  value: string;
  content?: React.ReactNode;
};

type TabsProps = {
  tabs: Tab[];
    containerClassName?: string;
  activeTabClassName?: string;
  tabClassName?: string;
  contentClassName?: string;
};

const tabs = [
  {
    title: "Product",
    value: "product",
    content: (
      <div className="w-full overflow-hidden relative rounded-2xl p-10 text-xl md:text-4xl font-bold text-foreground bg-muted h-[300px] border border-border">
        <p>Product Tab</p>
      </div>
    ),
  },
  {title: "Services",
    value: "services",
    content: (
      <div className="w-full overflow-hidden relative rounded-2xl p-10 text-xl md:text-4xl font-bold text-foreground bg-muted h-[300px] border border-border">
        <p>Services tab</p>
      </div>
    ),
  },
  {
    title: "Playground",
    value: "playground",
    content: (
      <div className="w-full overflow-hidden relative rounded-2xl p-10 text-xl md:text-4xl font-bold text-foreground bg-muted h-[300px] border border-border">
        <p>Playground tab</p>
      </div>
    ),
  },
 {
    title: "Content",
    value: "content",
    content: (
      <div className="w-full overflow-hidden relative rounded-2xl p-10 text-xl md:text-4xl font-bold text-foreground bg-muted h-[300px] border border-border">
        <p>Content tab</p>
      </div>
    ),
  },
  {
    title: "Random",
    value: "random",
    content: (
      <div className="w-full overflow-hidden relative rounded-2xl p-10 text-xl md:text-4xl font-bold text-foreground bg-muted h-[300px] border border-border">
        <p>Random tab</p>
      </div>
    ),
  },
];

const Tabs = ({
  tabs,
  containerClassName,
  activeTabClassName,
  tabClassName,
  contentClassName,
}: TabsProps) => {
  const [activeIdx, setActiveIdx] = useState(0);
  const [hovering, setHovering] = useState(false);

  const handleSelect = (idx: number) => {
    setActiveIdx(idx);
  };
const reorderedTabs = [
    tabs[activeIdx],
    ...tabs.filter((_, i) => i !== activeIdx),
  ];

  return (
    <>
      <div
        className={cn(
          "flex flex-row items-center justify-start [perspective:1000px] relative overflow-auto sm:overflow-visible no-visible-scrollbar max-w-full w-full",
          containerClassName,
        )}
      >
        {tabs.map((tab, idx) => {
          const isActive = idx === activeIdx;
          return (
            <button
            key={tab.value}
              onClick={() => handleSelect(idx)}
              onMouseEnter={() => setHovering(true)}
              onMouseLeave={() => setHovering(false)}
              className={cn("relative px-4 py-2 rounded-full", tabClassName)}
              style={{ transformStyle: "preserve-3d" }}
            >
              {isActive && (
                <motion.div
                  layoutId="clickedbutton"
                  transition={{ type: "spring", bounce: 0.3, duration: 0.6 }}
                  className={cn(
                    "absolute inset-0 bg-primary rounded-full",
                    activeTabClassName,
                  )}
                />
              )}
<span
                className={cn(
                  "relative block text-sm",
                  isActive ? "text-background": "text-foreground",
                )}
              >
                {tab.title}
              </span>
            </button>
          );
        })}
      </div>
      <FadeInStack
        tabs={reorderedTabs}
        hovering={hovering}
        className={cn("mt-10", contentClassName)}
      />
    </>
  );
};

type FadeInStackProps = {
  className?: string;
  tabs: Tab[];
  hovering?: boolean;
};

const FadeInStack = ({ className, tabs, hovering }: FadeInStackProps) => {
  return (
    <div className="relative w-full h-[300px]">
      {tabs.map((tab, idx) => (
        <motion.div
          key={tab.value}
          layoutId={tab.value}
          style={{
            scale: 1 - idx * 0.1,
            top: hovering ? idx * -15 : 0,
            zIndex: -idx,
            opacity: idx < 3 ? 1 - idx * 0.1 : 0,
          }}
          animate={{
            y: idx === 0 ? [0, 40, 0] : 0,
          }}
          className={cn("w-full h-full absolute top-0 left-0", className)}
        >
          {tab.content}
        </motion.div>
      ))}
    </div>
  );
};

export default function AnimatedTabMotion() {
  return (
    <>
      <div className="[perspective:1000px] relative flex flex-col max-w-5xl mx-auto w-full items-start justify-start mb-13">
        <Tabs tabs={tabs} />
      </div>
    </>
  );

}

Now, let’s break this down piece by piece.

Step 1: Define the Tab Data Types

type Tab = {
title: string;
value: string;
content?: React.ReactNode;
};
type TabsProps = {
tabs: Tab[];
containerClassName?: string;
activeTabClassName?: string;
tabClassName?: string;
contentClassName?: string;
};

The Tab type defines the shape of each tab item:

• title – the label rendered in the tab button.

• value – a unique key used to identify each tab (and as the Framer Motion layoutId).

• content – an optional React.ReactNode, meaning you can pass any JSX as the panel body.

The TabsProps type makes the Tabs component highly composable. Every visual layer has an override className, so you can restyle the active pill, individual tab buttons, and the content area independently without touching the core logic.

Step 2: Build the Tab Data Array

const tabs = [
{
title: “Product”,
value: “product”,
content: (

Product Tab

), }, // ... more tabs ];

Each tab’s content is a JSX element styled with Shadcn/ui semantic tokens like bg-muted, text-foreground and border-border. This is intentional: these tokens automatically adapt to your light/dark theme without any extra configuration.

You can replace these placeholder <div> panels with any real content: charts, forms, tables, media, whatever your use case demands.

Step 3: Build the Tabs Component (Tab Bar + State)

const [activeIdx, setActiveIdx] = useState(0);
const [hovering, setHovering] = useState(false);

Two pieces of state drive the entire component:

• activeIdx tracks which tab is currently selected (by array index).

• hovering tracks whether the user’s cursor is over any tab button, which is passed to FadeInStack to trigger the fan-out effect.

Reorder Tabs for the Stack Effect

const reorderedTabs = [
tabs[activeIdx],
…tabs.filter((_, i) => i !== activeIdx),
];

This is one of the most clever aspects of the architecture. Instead of showing only the active tab’s content, you always render all tab panels – but you put the active one first in the array. This is what enables the stacked-cards visual:

• Index 0 = the active panel, rendered on top with full scale and opacity.

• Index 1, 2 = the next panels, stacked behind with reduced scale and opacity.

• Index 3+ = hidden (opacity 0).

Render the Tab Buttons with a Spring Pill

{tabs.map((tab, idx) => {
const isActive = idx === activeIdx;
return (
   <button
    key={tab.value}
    onClick={() => handleSelect(idx)}
    onMouseEnter={() => setHovering(true)}
    onMouseLeave={() => setHovering(false)}
    className={cn(“relative px-4 py-2 rounded-full”, tabClassName)}
    style={{ transformStyle: “preserve-3d” }}
    >
    {isActive && (
       <motion.div
        layoutId=“clickedbutton”
        transition={{ type: “spring”, bounce: 0.3, duration: 0.6 }}
        className={cn(
        “absolute inset-0 bg-primary rounded-full”,
        activeTabClassName,
     )}
   />
)}
<span
    className={cn(
        “relative block text-sm”,
        isActive ? “text-background” : “text-foreground”,
    )}
    >
      {tab.title}
     </span>
  </button>
);
})}

The magic here is layoutId=“clickedbutton” on the motion.div. When only one element with a given layoutId is mounted at a time, Framer Motion tracks its position in the DOM. When it unmounts from one button and mounts onto another, Framer Motion automatically animates the transition is between the two DOM positions. This creates the sliding pill effect with zero manual calculation.

The transition config uses a spring with bounce: 0.3 a duration: 0.6, giving it a natural, slightly elastic feel rather than a mechanical linear slide.

The transformStyle: “preserve-3d” on the button enables 3D CSS transforms, which pair with the [perspective:1000px] on the container for a subtle depth effect.

Step 4: Build the FadeInStack Component

const FadeInStack = ({ className, tabs, hovering }: FadeInStackProps) => {
  return (
    <div className="relative w-full h-[300px]">
      {tabs.map((tab, idx) => (
        <motion.div
          key={tab.value}
          layoutId={tab.value}
          style={{
            scale: 1 - idx * 0.1,
            top: hovering ? idx * -15 : 0,
            zIndex: -idx,
            opacity: idx < 3 ? 1 - idx * 0.1 : 0,
          }}
          animate={{
            y: idx === 0 ? [0, 40, 0] : 0,
          }}
          className={cn("w-full h-full absolute top-0 left-0", className)}
        >
          {tab.content}
        </motion.div>
      ))}
    </div>
  );
};

Let’s unpack the visual logic for each motion.div:

scale: 1 - idx * 0.1

Each card behind the active one is scaled down by 10% per layer. So:

• Active card (idx 0): scale: 1.0

• Second card (idx 1): scale: 0.9

• Third card (idx 2): scale: 0.8

This creates clear depth separation between the stacked layers.

top: hovering ? idx * -15 : 0

When hovering is true, each card shifts upward by idx * 15px. The active card doesn’t move (idx 15 = 0), but the cards behind it fan out at -15px, -30px, and so on. This gives a satisfying “deck spreading” effect on hover.

zIndex: -idx

Negative z-index stacks cards in order: the active card sits on top (z-index 0), while subsequent cards descend further behind.

opacity: idx < 3 ? 1 - idx * 0.1 : 0

Cards at index 3 and beyond are hidden entirely. The first three cards fade progressively: 1.0, 0.9, 0.8.

animate={{ y: idx === 0 ? [0, 40, 0] : 0 }}

Only the active card (idx 0) gets this keyframe animation. When a tab is selected, and the reorderedTabs array is rebuilt, the new active card enters via a downward dip (y: 40) and bounces back to its rest position. This is a quick, tactile confirmation that the tab has changed.

layoutId={tab.value}

Each card also has a layoutId matching one value. When reorderedTabs is recomputed, and array positions shift, Framer Motion can track each card’s identity and animate it smoothly between positions, preventing jarring jumps.

Step 5: Compose the Page Component

export default function AnimatedTabMotion() {
  return (
    <div className="[perspective:1000px] relative flex flex-col max-w-5xl mx-auto w-full items-start justify-start mb-13">
      <Tabs tabs={tabs} />
    </div>
  );
}

The outer wrapper applies [perspective:1000px] – a Tailwind arbitrary property that sets the CSS perspective value. This is what gives the 3D depth to the transformStyle: “preserve-3d” on the tab buttons.

The max-w-5xl and mx-auto center the component on wide screens while items-start left-aligns the tab bar, which matches most real-world UI patterns.

Step 6: Customize the Component

Because Tabs accepts class-name overrides for every visual layer, so you can fully restyle the component to match your design system. Here’s an example with a darker active pill and a tighter layout:

<Tabs
  tabs={tabs}
  containerClassName="gap-1"
  tabClassName="text-xs px-3 py-1.5"
  activeTabClassName="bg-zinc-900 dark:bg-white"
  contentClassName="mt-6"
/>

You can also replace the placeholder content panels with real content. Here’s an example using a card with a real description:

const tabs = [
  {
    title: "Overview",
    value: "overview",
    content: (
      <div className="w-full rounded-2xl p-8 bg-muted border border-border h-[300px] flex flex-col gap-4">
        <h2 className="text-2xl font-bold text-foreground">Product Overview</h2>
        <p className="text-muted-foreground text-sm leading-relaxed">
          Our platform helps teams ship faster with a fully integrated design-to-code workflow.
        </p>
      </div>
    ),
  },
  // ...
];

Live Preview

Key Concepts Recap

Here’s a summary of the core Framer Motion techniques used in this component:

Conclusion

In this tutorial, you built a fully animated, theme-aware tab component using Shadcn/ui and Framer Motion. You learned how to:

• Use layoutId to create a spring-animated sliding pill indicator

• Render all tab panels simultaneously and reorder them to create a stacked card effect

• Drive hover and depth effects with inline reactive style props

• Apply Framer Motion keyframe animations for a tactile bounce entrance

• Keep the component fully customizable via class name overrides

This pattern, combining Shadcn/ui’s semantic design tokens with Framer Motion’s layout animations, scales well beyond tabs. You can apply the same layoutId and stack reorder technique to carousels, image galleries, notification toasts, and more.

You can explore the full component and more animated UI blocks at Shadcn Space, where the CLI command makes it trivial to drop production-quality components directly into your project.

Resources

• Shadcn Space Tabs Component

• Shadcn Space Getting Started Guide

• Framer Motion Documentation

• Shadcn/ui Documentation

• Video Tutorial on YouTube

I wrote this article with the help of Mihir Koshti (Sr. Full Stack Developer) – Connect on LinkedIn.

In this guide, you’ll learn how to build a dropdown menu using shadcn/ui. It’s a tool that works well with Tailwind CSS and Radix UI to help you make nice-looking, easy-to-use menus.

Table of Contents

• What is shadcn/ui?

• Why Use shadcn/ui for Dropdowns?

• Let’s Build a Dropdown Step-by-Step

  • Step 1: Start a New Project

  • Step 2: Add the Dropdown Menu Component

  • Step 3: Import What You Need

  • Step 4: Build a Simple Dropdown

  • Step 5: Make It Look Better

  • Step 6: Make It Work on All Screens

  • Step 7: Add Cool Icons

  • Step 8: It’s Already Accessible!

• Real-World Use Case: Country Dropdown with Flags

• Final Thoughts

💡 Prerequisites

Before we start, make sure you have:

• Basic knowledge of React and JavaScript

• Node.js and a package manager like npm, pnpm, or yarn are installed

• Familiarity with Tailwind CSS is a bonus, but not required

We’ll walk through everything step by step, so don’t worry if you’re not an expert yet.

What is shadcn/ui?

shadcn/ui is a group of tools (called components) that help you build parts of a website, like buttons, modals, and dropdowns. It’s built with Radix UI and styled using Tailwind CSS. It’s perfect if you’re using React or Next.js.

With shadcn/ui, you don’t get just styled components, you get full control over how everything works and looks. That makes it perfect for teams that want consistency in design without giving up flexibility.

Why Use shadcn/ui for Dropdowns?

Dropdown menus are a great use case for shadcn/ui because:

• It’s easy to use with keyboard and screen readers

• You can create custom looks using Tailwind CSS

• You control how it works and looks

• It works great in real websites and apps

• It integrates well with modern React workflows

Let’s Build a Dropdown Step-by-Step

Step 1: Start a New Project with shadcn/ui

You don’t need to set up React, Next.js, or Tailwind manually. Just run this command:

pnpm dlx shadcn@latest init

This will automatically create a new Next.js app with Tailwind CSS and shadcn/ui preconfigured.

Tip: You can also use npx instead of pnpm dlx if you prefer:

npx shadcn@latest init

Step 2: Add the Dropdown Menu Component

After your project is ready, add the dropdown component using:

npx shadcn@latest add dropdown-menu

This will pull in all the necessary components to create a dropdown menu.

Step 3: Import What You Need

In your React file, import the full dropdown module so you can access all its features:

import {
  DropdownMenu,
  DropdownMenuTrigger,
  DropdownMenuContent,
  DropdownMenuItem,
  DropdownMenuLabel,
  DropdownMenuSeparator,
  DropdownMenuShortcut,
  DropdownMenuGroup,
  DropdownMenuSub,
  DropdownMenuSubContent,
  DropdownMenuSubTrigger,
  DropdownMenuPortal,
} from "@/components/ui/dropdown-menu"

Step 4: Build a Simple Dropdown

Here’s a basic dropdown example:

export function ProfileMenu() {
  return (
    <DropdownMenu>
      <DropdownMenuTrigger asChild>
        <button className="px-4 py-2 bg-primary text-white rounded">
          Open Menu
        </button>
      </DropdownMenuTrigger>
      <DropdownMenuContent className="w-56">
        <DropdownMenuLabel>My Account</DropdownMenuLabel>
        <DropdownMenuSeparator />
        <DropdownMenuItem>Profile</DropdownMenuItem>
        <DropdownMenuItem>Settings</DropdownMenuItem>
        <DropdownMenuItem>Log out</DropdownMenuItem>
      </DropdownMenuContent>
    </DropdownMenu>
  )
}

This is just the start. You can add groups, submenus, and keyboard shortcuts for power users.

Step 5: Make It Look Better

Use Tailwind CSS to style your dropdown, and hover effects like this:

<DropdownMenu>
        <DropdownMenuTrigger asChild>
          <button className="px-3 py-1.5 bg-primary text-white text-sm font-medium rounded-md hover:bg-primary/90 transition-colors">
            Open Menu
          </button>
        </DropdownMenuTrigger>
        <DropdownMenuContent className="w-52 border-gray-200 shadow-lg rounded-md space-y-0.5">
          <DropdownMenuLabel className="text-xs text-gray-500">
            My Account
          </DropdownMenuLabel>
          <DropdownMenuSeparator className="border-t border-gray-100" />
          <DropdownMenuItem className="px-3 py-1.5 text-sm text-gray-700 hover:bg-gray-100 rounded-md cursor-pointer transition-colors">
            Profile
          </DropdownMenuItem>
          <DropdownMenuItem className="px-3 py-1.5 text-sm text-gray-700 hover:bg-gray-100 rounded-md cursor-pointer transition-colors">
            Settings
          </DropdownMenuItem>
          <DropdownMenuItem className="px-3 py-1.5 text-sm text-red-600 hover:bg-red-50 rounded-md cur

Step 6: Make It Work on All Screens

Want your dropdown to be responsive? Use Tailwind’s responsive classes:

<DropdownMenuContent className="w-full md:w-64">

You can also dynamically position the dropdown using Radix's built-in portal support.

Step 7: Add Cool Icons

Install Lucide icons:

npm install lucide-react

Then use them in your menu:

import { User, Settings, LogOut } from "lucide-react"

<DropdownMenuItem>
  <User className="mr-2 h-4 w-4" /> Profile
</DropdownMenuItem>

Icons help users scan options quickly – a great touch for UX.

Step 8: It’s Already Accessible!

shadcn/ui (thanks to Radix UI) makes your dropdown menu:

• Keyboard friendly

• Screen-reader ready

• Following best web practices

You don’t need to configure accessibility – it just works :)

Real-World Use Case: Country Dropdown with Flags

Looking for a more advanced dropdown? Here’s an amazing example that includes search, flag icons, and grouping:

👉 shadcn-country-dropdown.vercel.app

It’s open-source and a great place to see what’s possible with shadcn/ui.

Final Thoughts

Using shadcn/ui to create a dropdown menu is fast, simple, and powerful. You get great styling, accessibility, and full control over how things look and work. Whether you’re just starting out or building for production, this is a solid tool to use.

Dropdowns are just the beginning. shadcn/ui offers a whole library of headless components for building modern UIs.

I hope you found this article helpful! If you're building a SaaS product or any web app that involves user interaction or conversion, consider enhancing user trust with real-time notifications like modal pop-ups, sales pop up, etc.

When users tap a button, they expect it to respond smoothly. When data is loading, users expect some visual feedback. Even small touches, like a gentle bounce or a fading transition, can make an interface feel polished and professional.

For developers, motion graphics are now part of the job. Designers may create the initial assets, but it’s usually developers who bring them to life in the actual product.

That means knowing how to control animations with code, integrate them into app logic, and make sure they perform well across devices.

Fortunately, a number of powerful tools have emerged that make motion graphics more accessible to developers without requiring them to become expert animators.

Let’s dive into some of the best motion graphics tools that developers can use today, and why each one is worth learning.

Lottie

Lottie has become one of the most widely used tools for integrating motion graphics into mobile apps and websites.

Originally developed by Airbnb, Lottie lets designers create animations in Adobe After Effects and export them as lightweight JSON files using the Bodymovin plugin.

As a developer, you don’t have to recreate complex animations manually or deal with heavy video files. Instead, you load the JSON file into your app using the Lottie library, and the animation plays natively.

One of Lottie’s biggest advantages is its cross-platform support. Whether you’re building for iOS, Android, the web, React Native, or Flutter, Lottie works the same way.

The animations are rendered as scalable vector graphics, so they stay sharp on any screen size or resolution. This makes them perfect for things like onboarding screens, button interactions, loading indicators, and even full-screen animated backgrounds.

Lottie also gives you a lot of control through code. You can play, pause, loop, or even dynamically change the speed of an animation. If you want an animation to start when a user scrolls to a certain point or clicks a button, you can easily hook into your app’s logic and control the animation’s state.

This flexibility makes Lottie a favorite for developers who want designer-level animations without the usual headaches of file size, performance, or cross-platform compatibility.

GSAP

While Lottie is great for pre-designed animations, sometimes you want full programmatic control over how elements move and interact. That’s where GSAP, short for GreenSock Animation Platform, really shines.

GSAP allows you to animate anything on the web: HTML elements, SVG graphics, Canvas drawings, and even WebGL content. It’s used by professional web developers and interactive designers around the world for its precision, performance, and flexibility.

With GSAP, you write animations directly in JavaScript. You’re not importing files created in a design tool. Instead, you describe the animations in code, which gives you complete control over timing, sequencing, and interaction.

You can chain multiple animations together, create synchronized timelines, and easily coordinate animations across multiple elements. The syntax is both simple and powerful, allowing you to start with basic effects and scale up to complex sequences as needed.

One of GSAP’s standout features is how well it handles performance. Animations stay smooth even when animating many elements at once, and the library takes care of browser quirks so you don’t have to worry about inconsistencies across platforms.

If you’ve ever struggled with CSS transitions or vanilla JavaScript animations, GSAP feels like a breath of fresh air. You get pixel-perfect control with readable and maintainable code, even as your animations grow more complex.

Framer Motion

If you’re building modern web apps with React, Framer Motion offers a different kind of power.

Unlike GSAP, which works everywhere, Framer Motion is built specifically for React’s component model. Instead of managing animations through external scripts or event listeners, you define them directly in your JSX code alongside the rest of your component logic.

This declarative approach means you simply describe what you want to happen, and Framer Motion takes care of the rest. You specify target values for things like position, opacity, or scale, and the library smoothly transitions from the current state to the new one whenever props change.

This makes it incredibly easy to animate things like page transitions, hover effects, collapsible panels, and other common UI interactions.

Framer Motion also supports more advanced features out of the box, such as gesture-based animations, layout transitions, and shared element transitions between different routes or components.

These kinds of features can be very challenging to implement manually, but Framer Motion makes them approachable even for developers who aren’t animation experts.

Another benefit is how naturally Framer Motion fits into the React ecosystem. Since you’re not writing separate animation code, your logic stays tightly integrated with your app state and component structure. This reduces bugs, simplifies maintenance, and helps keep your codebase clean and organised.

Rive

Rive represents a new way of thinking about motion graphics, one that blurs the line between design and code.

Unlike tools that focus only on timeline-based animations, Rive adds state machines and logic directly into the animation itself. This allows you to create interactive, real-time animations that respond to user input or application state changes.

In Rive’s editor, designers build both the visuals and the interaction logic. You can define how animations transition between different states based on triggers that your app can control.

As a developer, you don’t have to write complex animation logic yourself. Instead, you simply send events to the Rive runtime and let it handle the animation transitions.

For example, imagine a character that waves when a user taps the screen, then smiles if a task is completed. With Rive, the designer creates both the waving and smiling animations and wires up the logic that connects them.

You just tell the animation which state to enter based on your app’s data. The result feels dynamic and interactive, like a small game embedded into your UI.

Rive works across platforms, including web, mobile, and game engines, and the exported files are lightweight enough to use even in performance-sensitive environments.

It’s a tool that empowers both designers and developers to create richer experiences without a ton of back-and-forth or complicated handoffs.

Three.js

Sometimes, 2D animations aren’t enough. When you need true 3D motion graphics in the browser, Three.js is the go-to library for developers.

While not strictly a motion graphics tool in the traditional sense, Three.js allows you to create complex 3D scenes, animate objects, and build immersive experiences entirely with JavaScript.

Three.js abstracts much of the complexity of WebGL, making it more approachable for developers who may not have a deep background in computer graphics. You can load 3D models, apply materials and lighting, set up cameras, and create fully interactive environments that respond to user input.

Animation in Three.js can involve simple tasks like rotating a model or more complex sequences like animated camera moves or physics-based simulations. Because you have full access to the scene graph, you can control every detail of how your objects move and behave.

This opens up possibilities for product visualizations, interactive demos, educational tools, and even web-based games.

While Three.js has a steeper learning curve than the other tools mentioned here, the payoff is significant. You’re no longer limited to flat surfaces and basic transitions. With Three.js, you can build fully immersive experiences that were once only possible in native apps or games.

Summary

As motion graphics become more important in modern interfaces, developers have an expanding toolbox to help them deliver polished, interactive experiences. Each tool has its own strengths, depending on the project and platform.

As a developer, you don’t need to master all of these tools at once. Start with the one that fits your current project needs, and build your motion graphics skills from there. With practice, you’ll discover that motion isn’t just a visual extra — it’s part of how your software communicates, guides, and delights your users.

Hope you enjoyed this article. You can learn more about me or connect with me on Linkedidn.

Design prototyping and testing are critical steps in optimizing website UX functionality. One study reported that improving UX design led to a 400% increase in website conversions.

For such an important task, we need the best possible tools and resources we can get. And lately I’ve been enjoying using Sourcegraph’s Cody. Cody is an AI tool that speeds up coding by helping you understand, write, and fix code. It accesses information from your entire codebase, and also references documentation pages, to provide context about functions and variables, help create new code, and improve your design system.

When combined with Tailwind CSS, which is a utility-first CSS framework, you can rapidly build UI components that are both functional and visually appealing.

In this tutorial, I’ll teach you how to build UIs faster with Cody and Tailwind CSS so you can leverage AI to streamline your workflow.

Prerequisites

• Basic understanding of JavaScript and front-end development.

• Familiarity with Tailwind CSS.

• Node.js installed on your system.

• A code editor like Visual Studio Code (VS Code).

• Cody. Sign up on Sourcegraph to get access (it’s free).

Table of Contents

• What Will We Be Building?

• How to Set Up Your Environment

• How to Create UI Components with AI

• More Complicated UIs

• How to Improve and Manage Existing Codebases with Cody

• Next Steps

What Will We Be Building?

Let’s build yet another Todo App, but with a spin. Each to-do item will have a timer that can be started, paused, and reset. This might be useful to track how much time you spend working on specific tasks.

From the Cody docs, Cody's chat allows you to add files and symbols as context in your messages.

• Type @ and then a filename to include a file as a context.

• Type @# and then a symbol name to include the symbol's definition as context. Functions, methods, classes, types, and so on are all symbols.

Even though Cody will be doing most of the heavy lifting, it’s great to have a plan of how we want the UI to look. Here are the wireframes I created with wireframe.cc:

Alright! Let’s get into it.

How to Set Up Your Environment

This tutorial uses Visual Studio Code, but the development process is similar across other code editors. If you haven’t set up an editor yet, choose one that suits your preference and install Node.js.

As of this article, Sourcegraph Cody is available on Visual Studio Code, Neovim, Cody CLI, Emacs, and all JetBrains IDEs

How to add Cody to your code editor

First, head over to the Cody landing page, click Get Cody for Free, and follow the prompts to sign up for a Sourcegraph account using your preferred authentication method—GitHub, GitLab, or Google.

Pick the right option for your code editor. If you’re using Visual Studio Code, that would be, Install Cody in VS Code.

Opening the extension in your code editor prompts a sign-in:

After signing in, we’re ready to go.

How to set up the project

We’ll be working with a Vite + React + TailwindCSS project, but these ideas can easily be applied to any other framework (think Vue, Astro, Svelte, or regular Vanilla JS) or styling library (like Bootstrap, Bulma, Foundation CSS, or anything you’d prefer).

Run the following command to create a new React project, abc-planning-todo-app:

npm create vite@latest abc-planning-todo-app -- --template react

Then install Tailwind CSS:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Next, update tailwind.config.js with this code to configure Tailwind CSS for the project:

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Delete everything in ./src/index.css and add the following Tailwind CSS directives:

@tailwind base;
@tailwind components;
@tailwind utilities;

How to Create UI Components with AI

For consistency, let’s pick a color palette we’ll use for our to-do app.

To use these colors in our Tailwind theme, we first need to give them descriptive names. Let's ask Cody for help!

For the rest of this article, all quotes represent a single prompt message used when chatting with Cody.

What would be good names for the following hex colors?

• 2B2D42

• 8D99AE

• EDF2F4

• EF233C

• D90429

And then,

Update @tailwind.config.js to include these 5 hex colors above:

/** @type {import('tailwindcss').Config} */
export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {
      colors: {
        'midnight-navy': '#2B2D42',
        'cloudy-sky': '#8D99AE',
        'ice-white': '#EDF2F4',
        'vibrant-red': '#EF233C',
        'ruby-red': '#D90429',
      },
    },
  },
  plugins: [],
}

How to create basic UI components

First, we create the Header component. With templates for relatively uncomplicated components (for example text inputs, headers, buttons and dropdowns), it’s as simple as providing a name for the component, and the copy content it should contain.

Create a simple React Header Component with only company name on the far left and company motto on the far right. Use the Tailwind theme @tailwind.config.js

Cody will generate a Header component, which you can then copy and paste into ./src/components/Header.jsx.

You can also save the code to a new file in your project directly from the Cody chat.

// ./src/components/Header.jsx
import React from 'react';
const Header = () => {
  return (
    <header className="bg-midnight-navy text-ice-white p-4 flex justify-between items-center">
      <div className="text-2xl font-bold">
        Company
      </div>
      <div className="text-cloudy-sky italic">
        Innovate. Create. Inspire.
      </div>
    </header>
  );
};
export default Header;

Next, create the Footer component with this prompt:

Create a simple React Footer Component with content Copyright C ABC Planning. Use the Tailwind theme @tailwind.config.js*. Ensure footer is always at the bottom of the viewport*

// ./src/components/Footer.jsx
import React from 'react';
const Footer = () => {
  return (
    <footer className="bg-midnight-navy text-ice-white p-4 text-center fixed bottom-0 w-full">
      <p>&copy; {new Date().getFullYear()} ABC Planning</p>
    </footer>
  );
};
export default Footer;

Let’s take a look at what we have so far.

More Complicated UIs

Next, we’ll need a container that will hold all our to-dos. Let’s ask Cody to create a to-do container component.

Create a React TodoContainer Component that will serve as a container for Todo items. Use the Tailwind theme @tailwind.config.js*. It should be mobile-responsive*.

We tell Cody:

• What we want (a React component)

• A brief description of how that component behaves/what it does (container for to-dos)

• Any additional context – stylesheets, preferences, conventions, or anything else.

// ./src/components/TodoContainer.jsx
import React from 'react';
const TodoContainer = ({ children }) => {
  return (
    <div className="bg-ice-white min-h-screen p-4 sm:p-6 md:p-8">
      <div className="max-w-4xl mx-auto">
        <h1 className="text-midnight-navy text-3xl font-bold mb-6">Todo List</h1>
        <div className="grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-4">
          {children}
        </div>
      </div>
    </div>
  );
};
export default TodoContainer;

A good Chat-oriented programming (CHOP) strategy is to separate the creation of markup from the creation of content. This simplifies the prompting process.

Cody can generate both very well, but trying to fine-tune a single prompt for both tasks might be challenging. Each prompt should have a clear, specific goal for best results.

Let's now focus on the TodoItem component and split it into sections:

• There's a to-do header which consists of a title with a border.

• There's a View details button.

• There's a timer showing how long ago the to-do was started.

• There are control buttons (which reflect the state of the to-do)

  Create a React TodoItem Component.

  It consists of:

  1. Task title. A header text with a border around it.

  2. A simplified link/button "View details" below the todo header box.

  3. A digital timer that shows hours, minutes, and seconds in the format 00:00:00.

  4. Todo actions - "Start", "Pause", "Reset". Use relevant colors for each. The timer should be able to be started, paused and reset when the respective button is pressed.

  It should look like a card (tall not wide) on a desktop.

  It will be used with @TodoContainer.jsx

  Use @tailwind.config.js theme

    // ./src/components/TodoItem.jsx
    import React, { useState, useEffect } from 'react';
    const TodoItem = ({ title }) => {
      const [time, setTime] = useState(0);
      const [isRunning, setIsRunning] = useState(false);
      useEffect(() => {
        let interval;
        if (isRunning) {
          interval = setInterval(() => {
            setTime((prevTime) => prevTime + 1);
          }, 1000);
        }
        return () => clearInterval(interval);
      }, [isRunning]);
      const formatTime = (seconds) => {
        const hours = Math.floor(seconds / 3600);
        const minutes = Math.floor((seconds % 3600) / 60);
        const secs = seconds % 60;
        return [hours, minutes, secs].map(v => v.toString().padStart(2, '0')).join(':');
      };
      const handleStart = () => setIsRunning(true);
      const handlePause = () => setIsRunning(false);
      const handleReset = () => {
        setIsRunning(false);
        setTime(0);
      };
      return (
        <div className="bg-ice-white rounded-lg shadow-md p-4 flex flex-col space-y-4 h-full">
          <h2 className="text-xl font-bold text-midnight-navy border-2 border-midnight-navy rounded p-2 text-center">
            {title}
          </h2>
          <button className="text-cloudy-sky hover:text-midnight-navy transition-colors">
            View details
          </button>
          <div className="text-3xl font-mono text-midnight-navy text-center">
            {formatTime(time)}
          </div>
          <div className="flex justify-between mt-auto">
            <button 
              onClick={handleStart} 
              className="bg-vibrant-red text-ice-white px-4 py-2 rounded hover:bg-ruby-red transition-colors"
            >
              Start
            </button>
            <button 
              onClick={handlePause} 
              className="bg-cloudy-sky text-midnight-navy px-4 py-2 rounded hover:bg-ice-white transition-colors"
            >
              Pause
            </button>
            <button 
              onClick={handleReset} 
              className="bg-midnight-navy text-ice-white px-4 py-2 rounded hover:bg-cloudy-sky transition-colors"
            >
              Reset
            </button>
          </div>
        </div>
      );
    };
    export default TodoItem;
  

  From our wireframes, each to-do will have a detail state when its description is visible and can be updated. We’ll tell Cody to update the existing TodoItem.jsx file:

  Update @TodoItem.jsx to have a second state, when the view detail button is pressed. In this state, the TodoItem is composed of the following elements only:

  1. Task header with the task title, same as before

  2. A textbox with a description of the task

  3. A save button, that emits an updateTask event, and switches the component back to its default state.

  Include animations between the transition to create a clean feel and experience

  
    // ./src/components/TodoItem.jsx
    import React, { useState, useEffect } from 'react';
    const TodoItem = ({ title, description = '', onUpdateTask }) => {
      const [time, setTime] = useState(0);
      const [isRunning, setIsRunning] = useState(false);
      const [isDetailView, setIsDetailView] = useState(false);
      const [taskDescription, setTaskDescription] = useState(description);
      useEffect(() => {
        let interval;
        if (isRunning) {
          interval = setInterval(() => {
            setTime((prevTime) => prevTime + 1);
          }, 1000);
        }
        return () => clearInterval(interval);
      }, [isRunning]);
      const formatTime = (seconds) => {
        const hours = Math.floor(seconds / 3600);
        const minutes = Math.floor((seconds % 3600) / 60);
        const secs = seconds % 60;
        return [hours, minutes, secs].map(v => v.toString().padStart(2, '0')).join(':');
      };
      const handleStart = () => setIsRunning(true);
      const handlePause = () => setIsRunning(false);
      const handleReset = () => {
        setIsRunning(false);
        setTime(0);
      };
      const handleViewDetails = () => setIsDetailView(true);
      const handleSave = () => {
        onUpdateTask({ title, description: taskDescription });
        setIsDetailView(false);
      };
      return (
        <div className="bg-ice-white rounded-lg shadow-md p-4 flex flex-col space-y-4 h-full transition-all duration-300 ease-in-out">
          <h2 className="text-xl font-bold text-midnight-navy border-2 border-midnight-navy rounded p-2 text-center">
            {title}
          </h2>
          {isDetailView ? (
            <>
              <textarea
                className="flex-grow p-2 border-2 border-cloudy-sky rounded resize-none transition-all duration-300 ease-in-out"
                value={taskDescription}
                onChange={(e) => setTaskDescription(e.target.value)}
                placeholder="Enter task description..."
              />
              <button 
                onClick={handleSave}
                className="bg-vibrant-red text-ice-white px-4 py-2 rounded hover:bg-ruby-red transition-colors"
              >
                Save
              </button>
            </>
          ) : (
            <>
              <button 
                onClick={handleViewDetails}
                className="text-cloudy-sky hover:text-midnight-navy transition-colors"
              >
                View details
              </button>
              <div className="text-3xl font-mono text-midnight-navy text-center">
                {formatTime(time)}
              </div>
              <div className="flex justify-between mt-auto">
                <button 
                  onClick={handleStart} 
                  className="bg-vibrant-red text-ice-white px-4 py-2 rounded hover:bg-ruby-red transition-colors"
                >
                  Start
                </button>
                <button 
                  onClick={handlePause} 
                  className="bg-cloudy-sky text-midnight-navy px-4 py-2 rounded hover:bg-ice-white transition-colors"
                >
                  Pause
                </button>
                <button 
                  onClick={handleReset} 
                  className="bg-midnight-navy text-ice-white px-4 py-2 rounded hover:bg-cloudy-sky transition-colors"
                >
                  Reset
                </button>
              </div>
            </>
          )}
        </div>
      );
    };
    export default TodoItem;
  

  Now let’s create a new root component that makes use of our components:

  Generate an App.jsx that makes use of @Header.jsx*,* @TodoItem.jsx*,* @TodoContainer.jsx*, and* @Footer.jsx appropriately. Use simple JavaScript variables as state data and implement whatever functions are relevant. Have a minimum of 5 to-do items.

  
    // ./src/App.jsx
    import React, { useState } from 'react';
    import Header from './components/Header';
    import TodoContainer from './components/TodoContainer';
    import TodoItem from './components/TodoItem';
    import Footer from './components/Footer';
    const App = () => {
      const [todos, setTodos] = useState([
        { id: 1, title: 'Complete project proposal', description: 'Draft and finalize the project proposal for the client meeting.' },
        { id: 2, title: 'Review code changes', description: 'Go through the pull requests and provide feedback on the code changes.' },
        { id: 3, title: 'Prepare presentation', description: 'Create slides for the upcoming team meeting presentation.' },
        { id: 4, title: 'Update documentation', description: 'Review and update the project documentation with recent changes.' },
        { id: 5, title: 'Team meeting', description: 'Attend the weekly team sync-up and discuss project progress.' },
      ]);
      const handleUpdateTask = (updatedTask) => {
        setTodos(todos.map(todo => 
          todo.id === updatedTask.id ? { ...todo, ...updatedTask } : todo
        ));
      };
      return (
        <div className="flex flex-col min-h-screen">
          <Header />
          <main className="flex-grow">
            <TodoContainer>
              {todos.map(todo => (
                <TodoItem 
                  key={todo.id}
                  title={todo.title}
                  description={todo.description}
                  onUpdateTask={(updatedTask) => handleUpdateTask({ id: todo.id, ...updatedTask })}
                />
              ))}
            </TodoContainer>
          </main>
          <Footer />
        </div>
      );
    };
    export default App;
  

  Here’s what we now have:

How to Improve and Manage Existing Codebases with Cody

To further boost your productivity, Cody offers prompts and commands.

You can save frequently used prompts for future use and share them with other team members within your organization. Commands offer quick, ready-to-use shortcuts for common coding tasks like writing, describing, fixing, and identifying code issues.

Let’s add documentation to our code!

Firstly, select the code you would like to generate documentation for, we’ll use TodoItem.jsx for this example. Run the Document Code command, and we get a JSDoc docstring for the Footer component class.

Let’s make our components more accessible and inclusive

We can save our favorite and frequently used chat prompts on the Prompt Library via the Sourcegraph's Web UI.

Let’s create a new prompt to improve the accessibility of our web app and ensure it adheres to the WCAG standard.

We can now use this prompt back in VS Code.

Above you can see the results from our accessibility prompt.

How to Use AI Responsibly for Code Generation

AI tools can significantly speed up your workflow, but it's essential to remember that AI is still a work in progress. As powerful as these tools can be, they can also make mistakes or "hallucinate," producing code that seems correct but doesn't actually work in your specific context.

To use AI responsibly for coding, it’s crucial to approach it from a point of understanding what needs to be done. Before relying on AI, make sure you have a solid grasp of the task at hand. AI works best when used as a productivity booster rather than a replacement for your expertise.

Here are a few key things to keep in mind when working with AI-generated code:

• Double-check the code: Always run and test the code generated by AI. Even if it looks correct at first glance, there could be subtle errors or inefficiencies. It's your responsibility to ensure the code is functional and meets your project’s requirements.

• Understand the output: Before using any AI-suggested code, take time to understand how it works. This will allow you to quickly identify any mistakes and integrate the code effectively with the rest of your project.

When used thoughtfully and carefully, AI can make your development process more efficient and help you focus on higher-level tasks. However, it’s essential to balance its use with human oversight to ensure the quality and accuracy of the code you're building.

Next Steps

Creating user-friendly UIs has traditionally been time-consuming and difficult to manage. But using Cody, we created an interactive and attractive user interface with minimal effort. Cody supported us throughout the entire development process.

Here are some potential enhancements you can make:

• We can’t create or delete tasks. Try to fix that.

• Develop a component to display total tasks and accumulated hours.

• Add test cases for each component. We can do this quickly using the Generate Unit Tests command.

If you enjoyed learning about Cody, you can try more of its features and applications. Sign up for a free, forever account and boost your productivity designing, creating, documenting, and managing applications.

Further reading

If you want to learn more, you can read this article about chat-oriented programming (CHOP) and how to use Cody for it: Chat-oriented programming (CHOP) in action.

At the time, there was no built-in composable to display tooltips and there were several alternative solutions circling online. The problem with those solutions was that once Jetpack Compose released newer versions, those solutions might break. So it wasn’t ideal and the community was left hoping that sometime in the future, support would be added for tooltips.

I’m glad to say that since version 1.1.0 of Compose Material 3, we now have built in tooltip support. 👏

While this in itself is great, more than a year has passed since that version was released. And with subsequent versions, the API related to tooltips changed drastically as well.

If you go over the changelog, you will see how the public and internal APIs have changed. So bear in mind, that when you read this article, things may have continued to change as everything related to Tooltips is still marked by the annotation ExperimentalMaterial3Api::class.

❗️ The version of material 3 used for this article is 1.2.1, which was released on March 6th, 2024

Tooltip Types

We now have support for two different types of tooltips:

1. Plain tooltip

2. Rich media tooltip

Plain Tooltip

You can use the first kind to provide information about an icon button that wouldn’t be clear otherwise. For example, you can use a plain tooltip to indicate to a user what the icon button represents.

To add a tooltip to your application, you use the TooltipBox composable. This composable takes several arguments:

fun TooltipBox(
    positionProvider: PopupPositionProvider,
    tooltip: @Composable TooltipScope.() -> Unit,
    state: TooltipState,
    modifier: Modifier = Modifier,
    focusable: Boolean = true,
    enableUserInput: Boolean = true,
    content: @Composable () -> Unit,
)

Some of these should be familiar to you if you have used Composables before. I’ll highlight the ones that have a specific use case here:

• positionProvider - Of PopupPositionProvider type, and is used to calculate the position of the tooltip.

• tooltip - This is where you can design the UI of how the tooltip will look like.

• state - This holds the state that is associated with a specific Tooltip instance. It exposes methods like showing/dismissing the tooltip and when instantiating an instance of one, you can declare if the tooltip should be persistent or not (meaning if it should keep displaying on the screen until a user performs a click action outside the tooltip).

• content - This is the UI that the tooltip will display above/below.

Here is an example of instantiating a BasicTooltipBox with all the relevant arguments filled in:

@OptIn(ExperimentalFoundationApi::class, ExperimentalMaterial3Api::class)
@Composable
fun BasicTooltip() {
    val tooltipPosition = TooltipDefaults.rememberPlainTooltipPositionProvider()
    val tooltipState = rememberBasicTooltipState(isPersistent = false)

    BasicTooltipBox(positionProvider = tooltipPosition,
        tooltip =  { Text("Hello World") } ,
        state = tooltipState) {
        IconButton(onClick = { }) {
            Icon(imageVector = Icons.Filled.Favorite, 
                 contentDescription = "Your icon's description")
        }
    }
}

Jetpack Compose has a built in class called TooltipDefaults. You can use this class to help you instantiate arguments that make up a TooltipBox. For instance, you could use TooltipDefaults.rememberPlainTooltipPositionProvider to correctly position the tooltip in relation to the anchor element.

Rich Tooltip

A rich media tooltip takes more space than a plain tooltip and can be used to provide more context about the functionality of an icon button. When the tooltip is shown, you can add buttons and links to it to provide further explanation or definitions.

It is instantiated in a similar way as a plain tooltip, inside of a TooltipBox, but you use the RichTooltip composable.

TooltipBox(positionProvider = tooltipPosition,
        tooltip = {
                  RichTooltip(
                      title = { Text("RichTooltip") },
                      caretSize = caretSize,
                      action = {
                          TextButton(onClick = {
                              scope.launch {
                                  tooltipState.dismiss()
                                  tooltipState.onDispose()
                              }
                          }) {
                              Text("Dismiss")
                          }
                      }
                  ) {
                        Text("This is where a description would go.")
                  }
        },
        state = tooltipState) {
        IconButton(onClick = {
            /* Icon button's click event */
        }) {
            Icon(imageVector = tooltipIcon,
                contentDescription = "Your icon's description",
                tint = iconColor)
        }
    }

A few things to notice about a Rich tooltip:

1. A Rich tooltip has support for a caret.

2. You can add an action (that is, a button) to the tooltip to give users an option to find out more information.

3. You can add logic to dismiss the tooltip.

Edge Cases

When you choose to mark your tooltip state as persistent, it means that once the user interacts with the UI that shows your tooltip, it will stay visible until the user presses anywhere else on the screen.

If you looked at the example of a Rich tooltip from above, you might have noticed that we have added a button to dismiss the tooltip once it’s clicked.

There is a problem that happens once a user presses that button. Since the dismiss action is performed on the tooltip, if a user wants to perform another long press on the UI item that invokes this tooltip, the tooltip won’t be shown again. This means that the state of the tooltip is persistent on it being dismissed. So, how do we go about and resolve this?

In order to “reset” the state of the tooltip, we have to call the onDispose method that is exposed through the tooltip state. Once we do that, the tooltip state is reset and the tooltip will be shown again when the user performs a long press on the UI item.

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun RichTooltip() {
    val tooltipPosition = TooltipDefaults.rememberRichTooltipPositionProvider()
    val tooltipState = rememberTooltipState(isPersistent = true)
    val scope = rememberCoroutineScope()

    TooltipBox(positionProvider = tooltipPosition,
        tooltip = {
                  RichTooltip(
                      title = { Text("RichTooltip") },
                      caretSize = TooltipDefaults.caretSize,
                      action = {
                          TextButton(onClick = {
                              scope.launch {
                                  tooltipState.dismiss()
                                  tooltipState.onDispose()  /// <---- HERE
                              }
                          }) {
                              Text("Dismiss")
                          }
                      }
                  ) {

                  }
        },
        state = tooltipState) {
        IconButton(onClick = {  }) {
            Icon(imageVector = Icons.Filled.Call, contentDescription = "Your icon's description")
        }
    }
}

Another scenario where the tooltip state does not reset is if instead of calling ourselves for the dismiss method per a user’s action, the user clicks outside of the tooltip, causing it to be dismissed. This calls the dismiss method behind the scenes and the tooltip state is set to dismissed. Long pressing on the UI element to see our tooltip again will result in nothing.

Our logic that calls the tooltip’s onDispose method does not get triggered, so how can we reset the tooltip’s state?

Currently, I haven’t been able to figure this out. It might be related to the tooltip’s MutatorMutex. Maybe with upcoming releases, there will be an API for this. I did notice that if other tooltips are present on the screen and they are pressed, this resets the previously clicked upon tooltip.

If you would like to see the code featured here, you can go to this GitHub repository

If you would like to see tooltips in an application, you can check it out here.

References

• Material3 Tooltip Overview

• Tooltip Defaults

• Tooltip Source Code

In the old system, we used OnClickListeners and other interfaces. In Compose, we can take full advantage of Kotlin’s Sealed Classes, Function Types and Lambda Expressions.

If you do not know what a composable is, consider reading this article which explains the fundamentals.

How to Model UI Events with a Sealed Class

First, we must learn what is meant by UI Events and how to model them with Sealed Classes.

I have described this same process for Java and Kotlin (with the old view system) before, so I will keep this brief.

The Process

For each screen or sub-screen of your UI, ask yourself this question: What are all the different ways which the user can interact with it?

Let's take an example from my first app built fully in compose, Graph Sudoku:

Screenshot of a Sudoku Android App

The sealed class I use to represent the UI interactions of this screen looks like this:

sealed class ActiveGameEvent {
    data class OnInput(val input: Int) : ActiveGameEvent()
    data class OnTileFocused(val x: Int, 
    val y: Int) : ActiveGameEvent()
    object OnNewGameClicked : ActiveGameEvent()
    object OnStart : ActiveGameEvent()
    object OnStop : ActiveGameEvent()
}

To explain briefly:

• OnInput represents a user touching an input button (like 0, 1, 2, 3, 4)

• OnTileFocused represents a user selecting a tile (like the amber highlighted one)

• OnNewGameClicked is self-explanatory

• OnStart and OnStop are lifecycle events which my composables do not care about, but they are used in the Activity which acts as a Container for the composables

Once you have your sealed class set up, you can now handle a wide variety of events using a single event handler function. Sometimes it might make more sense to have multiple event handler functions, so keep in mind that this approach must be adapted to your project's specific requirements.

How to Connect Your Software Architecture

What you have handling these events is totally up to you. Some people think that MVVM is the golden standard of software architectures, but it seems like more and more people are realizing that there is no single architecture which works best for every situation.

For Android with Compose, my current approach is to use a very 3rd party minimalist approach which typically has these things in each feature (screen):

• A (Presentation) Logic class as an event handler

• A ViewModel to store the data necessary to render the View (as the name implies)

• An Activity which acts as a Container (not a god object)

• Composables to form the View

Model-View-Whatever

I do not care what you use as long as you are applying separation of concerns. This is how I arrived at this architecture, by simply asking what should and should not be put together in the same class.

Whether you want your ViewModel, a Fragment, or an Activity to be your event handler, all of them can be set up the same way: Function Types!

Within your class of choice, set up an event handler function which accepts your sealed class as its argument:

class ActiveGameLogic(
    private val container: ActiveGameContainer?,
    private val viewModel: ActiveGameViewModel,
    private val gameRepo: IGameRepository,
    private val statsRepo: IStatisticsRepository,
    dispatcher: DispatcherProvider
) : BaseLogic<ActiveGameEvent>(dispatcher),
    CoroutineScope {
    //...
    override fun onEvent(event: ActiveGameEvent) {
        when (event) {
            is ActiveGameEvent.OnInput -> onInput(
                event.input,
                viewModel.timerState
            )
            ActiveGameEvent.OnNewGameClicked -> onNewGameClicked()
            ActiveGameEvent.OnStart -> onStart()
            ActiveGameEvent.OnStop -> onStop()
            is ActiveGameEvent.OnTileFocused -> onTileFocused(event.x, event.y)
        }
    }
    //...
}

This approach is very organized and makes it easy to test every Unit in this 3rd party library free class through a single entry point.

However, we are not done yet. Naturally, we need a way to get a reference to this event handler function, onEvent, to our Composables. We can do this using a function reference:

class ActiveGameActivity : AppCompatActivity(), ActiveGameContainer {
    private lateinit var logic: ActiveGameLogic

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val viewModel = ActiveGameViewModel()

        setContent {
            ActiveGameScreen(
                onEventHandler = logic::onEvent,
                viewModel
            )
        }

        logic = buildActiveGameLogic(this, viewModel, applicationContext)
    }

      //...
}

I am sure some of you are wondering why I am using an Activity. You can ask me during a livestream Q&A sometime for a detailed answer.

In short, Fragments appear to be a bit pointless with Compose with my approach to architecture (I do not use Jetpack Navigation), and there is nothing wrong with using Activities as a feature specific container. Just avoid writing god activities, basically.

To be specific, the way you make a reference to a function in Kotlin, is by providing the class/interface name (or skip that if it is a Top-Level function), followed by two colons, and the name of the function without any arguments or brackets:

onEventHandler = logic::onEvent

How to Replace onClickListener With Jetpack Compose onClick Modifier

With that stuff ready, we can look at how this works within the composable. Naturally, your root composable will need the event handler function as a parameter:

@Composable
fun ActiveGameScreen(
    onEventHandler: (ActiveGameEvent) -> Unit,
    viewModel: ActiveGameViewModel
) {
//...
}

It can be a bit tricky to get function type syntax correctly, but understand that this really is a reference to a function, which is not so different from a reference to a class.

Just as you should not build god objects, you should not build giant composables:

1. Break your UI down into the smallest reasonable parts

2. Wrap them in a composable function

3. For each composable which has a UI interaction associated with it, it must be given a reference to your event handler function

Here is a composable which represents the input buttons of the Sudoku app, which is given the event handler by reference:

@Composable
fun SudokuInputButton(
    onEventHandler: (ActiveGameEvent) -> Unit,
    number: Int
) {
    Button(
        onClick = { onEventHandler.invoke(ActiveGameEvent.OnInput(number)) },
        modifier = Modifier
            .requiredSize(56.dp)
            .padding(2.dp)
    ) {
        Text(
            text = number.toString(),
            style = inputButton.copy(color = MaterialTheme.colors.onPrimary),
            modifier = Modifier.fillMaxSize()
        )
    }
}

To actually pass the event to the logic class, we must use the invoke function, which will accept arguments as per the function type definition (which accepts an ActiveGameEvent in this case).

At this point, you are ready to handle UI interaction events in Kotlin (compose or not) by taking full advantage of this beautiful and modern programming language.

If you liked this article, share it on social media and consider checking out the resources below to support an independent programmer and content creator.

Social

You can find me on Instagram here and on Twitter here.

Here are some of my tutorials & courses

https://youtube.com/wiseass https://www.freecodecamp.org/news/author/ryan-michael-kay/ https://skl.sh/35IdKsj (introduction to Android with Android Studio)

While this is a beginner's guide to Compose, it will not be a beginner's guide to Android – so you should have built at least an application or two (though not in Compose, necessarily).

Before we begin, I was initially planning to write a follow up article directed towards more senior developers until I came across Leland Richardson’s two part article series. Leland is not only a Software Engineer working on the Jetpack Compose team, but I see that he is a great writer as well.

While I feel my article will stand on its own as an introduction to the basics of Jetpack Compose, I strongly suggest you read his articles once you have gained some practical experience with Compose (or right away if you prefer to learn that way).

Key Terms/Concepts Explained in this article:

• A brief review of the old View System and Hierarchy

• Composables and how they stand in relation to Views

• Recomposition and how to avoid doing it very poorly!

What Is A Composable?

In this section, we will discuss the most fundamental part of the Jetpack Compose library. If you are a seasoned Android developer, you may wish to skip to the sub-section titled “Are Composables Views?”

If you are not already familiar with the View system, you should read the next section as it is necessary to motivate and understand what a Composable is.

View Hierarchy

In the context of the Android SDK (the libraries we use to make user interfaces on this platform), a View is what we use to give structure and style to our applications.

It is the most fundamental kind of building block or element of a given user interface (UI), and each of these building blocks will contain the following kinds of information (among other things):

• X and Y start and end positions which tell the computer where to draw the view on the device screen

• Color and alpha (transparency) values

• Font information, text, symbols, and images

• Behaviour based on events such as user interaction (clicks) or changes in the application’s data (more on that later)

It is important to understand that a View can be something like a button (commonly referred to as a “widget”), but it can also be a container of the whole screen, part of the screen, or for other child Views.

Such containers are commonly referred to as Layouts or Viewgroups depending on the context. And, while sharing most of the same kinds of information as a widget, they also contain information about how to arrange and display other Views which are nested within them.

With that in mind, we get to the important part of this review of the View system: The View Hierarchy. For Web Developers, the View Hierarchy is essentially Android’s version of the Document Object Model (DOM).

For Android Developers, you can think of the View Hierarchy as a virtual representation of all the Views which you defined either in XML files or programmatically in Java or Kotlin.

To illustrate this, let's look at such an XML file (there’s no need to study it closely, just note the names). Then, using a debugger/stepper tool, we will look at what it looks like in the memory space of the Fragment which inflates this file:

fragment_hour_view.xml:

<?xml version=”1.0" encoding=”utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android=”http://schemas.android.com/apk/res/android"
android:layout_width=”match_parent”
android:layout_height=”match_parent”
android:id=”@+id/root_hour_view_fragment”
xmlns:app=”http://schemas.android.com/apk/res-auto"
>
<androidx.compose.ui.platform.ComposeView
android:id=”@+id/tlb_hour_view”
//...
 />
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_one”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_two”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_three”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_four”
//...
/>
</androidx.constraintlayout.widget.ConstraintLayout>

Memory Space of (Fragment)HourView.kt:

Image of a View Hierarchy

The debugger and stepper tools are some of my favourite ways to learn about what is going on under the hood of the code that I use from various libraries. Give it a try some time!

The purpose of showing you this XML file and what it turns into in a process (a process is simply a program that is running on a device), is to demonstrate how nested Views in an XML file translate into a nested View Hierarchy at runtime.

Hopefully, with a simple but concrete model of how the old system works, we can compare it with the new one.

Are Composables Views?

This was one of the first questions I asked when I started working with Compose, and the answer I have arrived at is both yes and no.

Yes, in the sense that a Composable fulfills the same conceptual role as a View in the old system. A Composable can be a widget like a button, or a container such as a ConstraintLayout (it is worth noting that there is a Composable implementation of ConstraintLayout available).

No, in the sense that the UI is no longer represented virtually in a View Hierarchy (apart from situations involving interoperability). With that being said, compose does not use magic to virtually represent and keep track of the UI. This means that it must have its own thing which is conceptually similar to a View Hierarchy.

Let us take a very brief look at this thing. Here, we have an Activity which uses the setContent {…} function to bind a Composable to itself:

ActiveGameActivity.kt:

class ActiveGameActivity : AppCompatActivity(), ActiveGameContainer {
private lateinit var logic: ActiveGameLogic
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val viewModel = ActiveGameViewModel()
    setContent {
        ActiveGameScreen(
            onEventHandler = {
                logic.onEvent(it)
            },
            viewModel
        )
    }
    logic = buildActiveGameLogic(this, viewModel, applicationContext)
}
//…
}

ActiveGameScreen.kt:

@Composable
fun ActiveGameScreen(
    onEventHandler: ((ActiveGameEvent) -> Unit),
    viewModel: ActiveGameViewModel
) {
    //...

    GraphSudokuTheme {
        Column(
            Modifier
                .background(MaterialTheme.colors.primary)
                .fillMaxHeight()
        ) {
            ActiveGameToolbar(
                clickHandler = {
                    onEventHandler.invoke(
                        ActiveGameEvent.OnNewGameClicked
                    )
                }
            )

            Box {
              //content
            }
        }
    }
}

In Compose, the View Hierarchy is replaced with something that we can locate if we dig really deeply into the mWindow field of this Activity. Within that field is the conceptual replacement of the View Hierarchy: The **Composer** and its **slotTable**.

At this point, if you want a detailed overview of the Composer and its slotTable, I must again suggest that you read Leland’s article (he goes into detail in part 2). There is more to the Compose Hierarchy than the Composer and its slotTable, but that should be sufficient to get us started.

In general terms, Jetpack Compose uses what we might call its Compose Hierarchy (which is made of, and managed by things like the Composer and its slotTable).

Again, this is the same conceptual idea as the View hierarchy, a bunch of objects in memory space which collectively represent the UI, but it is implemented very differently.

There's an important difference, though, which is tricky to understand technically, but easy to understand in principle. This is the way in which Compose handles updates to the Compose Hierarchy: Recomposition.

Recomposition: How To Update Compose UI

For my ESL friends, the word Compose comes from the latin componere, which roughly means “to put together.” Someone who writes music is often called a “Composer,” which can be thought of as the one who puts together the notes coming from one or more instruments into a composition (song).

Putting together implies that there are individual pieces. It's important to understand that almost any good software developer makes at least some effort to break their code down into the smallest reasonable parts.

I mention reasonable, because I think principles like DRY (Don’t Repeat Yourself) should be followed only to the extent that they solve more problems than they create.

There are many benefits to applying this concept, which is often called modularity, (or as I prefer, Separation of Concerns, or SOC). I am aware that some of you reading this might think I am just copying what Leland said in his article, but I have been talking about SOC as the Golden Principle Of Software Architecture for many years already.

Where this plays into Compose, is the same principle which we see in the popular Javascript library React. When done properly, Compose will only “recompose” (redraw, re-render, update, whatever) the Composables (parts/elements of the UI) which need to be recomposed.

This is ENORMOUSLY important when it comes to the performance of an application. This is because redrawing the UI, whether in the old View system or in Compose, is costly for system resources.

In case you were not aware, the entire purpose of the old RecyclerView (which was the first thing I ever made a tutorial on back in 2016!) was to employ the ViewHolder pattern to a list of data. This avoided the need to constantly inflate (make) new Views for each list item.

My goal in this article was to focus mostly on the theory, as I will be writing plenty of practical content over the next few months. However, I will finish the article off with a story from my direct experience, which will help you to further understand how recomposition works, and how to avoid doing it very poorly!

The Stopwatch Example

For my first full Compose application, I decided to build Sudoku. There are a number of reasons why, including the fact that I wanted a project which did not have an insanely complicated UI. I also wanted the chance to deep dive into Graph DS and Algos, which are quite suitable for Sudoku puzzles.

One thing I wanted was a Stopwatch which would keep track of how long it took the user to complete a puzzle:

Graph Sudoku puzzle

As is often the case in my profession, I expected this timer to be much easier to add than it really was. I messed around with Android’s Chronometer class as well as the Java Timer class, and both of them presented different but still application-breaking problems.

Eventually I took a step back and realized that I was writing in Kotlin. So I set up a Coroutine based timer in my presentation logic class (it ended up making the most sense to put it there), which would update my viewmodel each second:

Class ActiveGameLogic(…):…{
//…
inline fun startCoroutineTimer(
    delayMillis: Long = 0,
    repeatMillis: Long = 1000,
    crossinline action: () -> Unit
) = launch {
    delay(delayMillis)
    if (repeatMillis > 0) {
        while (true) {
            action()
            delay(repeatMillis)
        }
    } else {
        action()
    }
}
private fun onStart() =
launch {
    gameRepo.getCurrentGame(
    { puzzle, isComplete ->
        viewModel.initializeBoardState(
            puzzle,
            isComplete
    )
        if (!isComplete) timerTracker = startCoroutineTimer {
            viewModel.updateTimerState()
        }
    },{
        container?.onNewGameClick()
    })
}
//…
}

The ViewModel (not from AAC – I write my own VMs. But Compose already has good interoperability with AAC VMs from what I can see.) exposed references to callback functions, which is what I would use to update my Composables:

class ActiveGameViewModel {
    //…
    internal var subTimerState: ((Long) -> Unit)? = null
    internal var timerState: Long = 0L
    //…
    internal fun updateTimerState(){
        timerState++
        subTimerState?.invoke(timerState)
    }
//…
}

Now comes the important part! We can trigger recomposition of the Compose Hierarchy by using certain features of compose, such as the remember function:

var timerState by remember {
    mutableStateOf(“”)
}

If you must know, these features store the state of whatever you are remembering in the slotTable. In short, the word state here means the current “state” of the data, which starts out being just an empty String.

Here is where I screwed things up. I had pulled my simple timer composable into its own function (applied SOC), and I was passing in timerState as a parameter to that composable.

However, the above snippets were sitting in the parent composable of the timer, which was a container for the most complicated portion of the UI (a 9x9 Sudoku requires a large number of widgets):

@Composable
fun GameContent(
    onEventHandler: (ActiveGameEvent) -> Unit,
    viewModel: ActiveGameViewModel
) {
    Surface(
        Modifier
            .wrapContentHeight()
            .fillMaxWidth()
    ) {
        BoxWithConstraints(Modifier.background(MaterialTheme.colors.primary)) {
            //…
            ConstraintLayout {
                val (board, timer, diff, inputs) = createRefs()
                var isComplete by remember {
                    mutableStateOf(false)
                }
                var timerState by remember {
                    mutableStateOf("")
                }
                viewModel.subTimerState = {
                    timerState = it.toTime()
                }
                viewModel.subIsCompleteState = { isComplete = it }
            //…Sudoku board
            //Timer
                Box(Modifier
                    .wrapContentSize()
                    .constrainAs(timer) {
                        top.linkTo(board.bottom)
                        start.linkTo(parent.start)
                    }
                    .padding(start = 16.dp))
                {
                    TimerText(timerState)
                }
            //…difficulty display
            //…Input buttons
            }
        }
    }
}
@Composable
fun TimerText(timerState: String) {
    Text(
        text = timerState,
        style = activeGameSubtitle.copy(color = MaterialTheme.colors.secondary)
    )
}

This was causing some considerable lag and unresponsiveness. By making heavy usage of the debugger, I was able to find out why. Because my timerState variable was created and updated inside the parent Composable, it was triggering a recomposition of that entire portion of the UI. Every. Single. Tick.

After moving the appropriate code into the TimerText composable, things worked very smoothly:

@Composable
fun TimerText(viewModel: ActiveGameViewModel) {
    var timerState by remember {
        mutableStateOf("")
    }

    viewModel.subTimerState = {
        timerState = it.toTime()
    }

    Text(
        text = timerState,
        style = activeGameSubtitle.copy(color = MaterialTheme.colors.secondary)
    )
}

Hopefully I have given you a working understanding of recomposition and one of the biggest ways to do it incorrectly.

Avoiding unnecessary recompositions is incredibly important for performance. And so far it seems that applying SOC rigorously, even to the point of keeping remember state in separate composables, should become standard practice.

Resources & Support

If you liked this article, please share it on social media and check out my other articles on freeCodeCamp here. I also have a YouTube channel with hundreds of tutorials, and am an active writer on various platforms.

Connect with me on social media

You can find me on Instagram here and on Twitter here.

Also, I want to point out the single resource I used to get started with Jetpack Compose: Working code samples from good developers.

User story #13 gives a lot of people trouble. It reads:

The navbar should always be at the top of the viewport.

Non-fixed, normal navbar

Imagine you have the following HTML:

...
<header id="header">
  <img src="https://static1.squarespace.com/static/54d3e88ce4b0be204d0da36a/t/566f5b70bfe873371e44c7b0/1525197822184/" alt="logo" id="header-img">
  <nav id="nav-bar">
    <ul> 
      <li><a href="#about-us" class="nav-link">About Us</a></li>
      <li><a href="#videos" class="nav-link">Demo</a></li>
      <li><a href="#photos" class="nav-link">Photo Gallery</a></li>
      <li><a href="#contact-us" class="nav-link">Contact</a></li>
  </nav>
</header>
...

But when you scroll down the page, the navbar eventually leaves the view:

How to create a fixed navbar

To create a fixed navbar, or a navbar that's always at the top of the viewport even as you scroll down the page, there are a few things you need to do.

First, target the header and fix it to the page with the following rule:

header {
  position: fixed;
}

You'll notice that the navbar contracts to its default width, so set its width to the full width of the page:

header {
  position: fixed;
  width: 100%;
}

Depending on the display properties of the other elements, you may need to manually set the top and left positions of the navbar:

header {
  position: fixed;
  width: 100%;
  top: 0;
  left: 0;
}

Then all you need to do is apply some extra styling to get things looking good:

header {
  position: fixed;
  width: 100%;
  top: 0;
  left: 0;
  background-color: #cc0000;
  color: white;
  font-family: 'Exo 2', sans-serif;
  padding: 1em;
}

Fixed navbar — the result

After that, your navbar should still be visible even as you scroll down the page:

If you had asked me four years ago, when I became a CS graduate, what kind of career path I saw myself following, I probably would have told you back-end Java development or something similar. I was never creative, in the paint meets canvas kind of way, so I didn’t really consider a career path involving front-end development and design.

As we all know, things change. Over the course of my career, I have become more and more interested in UI development and design. I have been lucky enough in my job to have gained exposure to front-end development and to have been allowed to invest time in improving the skills necessary to be a front-end developer.

Over the past 12 months, I have been striving to improve my understanding of UI/UX design, both because of personal interest and to allow me to be more effective when working with designers.

In this post, I would like to share the lessons I have learned, the resources I have gathered, and the mistakes I have made in the hopes that other developers will be able to learn from my journey.

Table of Contents

• It’s not just talent
• Look, think, steal
• Learn the theory
• Build something
• Don’t give up
• Resources
• Conclusion

It’s not just talent

This one seems obvious to me now, but there was a time when I thought that designers were wizards that were born with the ability to create amazing looking apps, and websites.

It turns out that they’re not. They have just worked hard to perfect their craft. In the same way that learning to code comes easier to some people, there are people who will have a natural talent for design, but talent doesn’t mean much without hard work.

Design is something that can be learned. Don’t make the mistake I did and write yourself off because you’re not creative in the traditional sense. Solving programming problems takes creativity; think about solving design challenges in the same way.

Look, think, steal

In the same way that reading good code will help you become a better developer, learning from what others have created will help you become a better designer.

The next time you visit a website or use an app, look at it and really think about why it looks and behaves the way it does. Why are the elements are placed where they are? Why is that button a particular color? Why do you have to perform actions in a certain order?

Take Medium’s applause button for example. Why didn’t they just use a “like” button like every other social media website? In my opinion, it was a clever design decision not to. Instead, they are able to reinforce the idea of community that drives the site by carefully designing an interaction. Giving an article or response fifty claps takes time for a user to do, but it helps them to really connect with the content they are viewing and the person who created it.

Sites like Awwwards and Dribbble have proven invaluable to me in the last year. Many of the designs I have created have taken liberal inspiration from the creations of other great designers.

Learn the theory

When I first started putting together designs of my own, I couldn’t figure out why they looked and behaved so poorly. The flows were awkward, the colors mismatched, and the layouts were inconsistent.

I thought I could just jump straight in and use my development knowledge along with my basic knowledge of how sites should work, as a user, and it would work out fine.

I was very, very wrong. I ended up creating designs from a developers point of view, instead of using design theory as a base.

Developers know how a site works, but designers know how a site behaves and feels. There is a big gap that you can only fill by gaining a foundation in design knowledge.

To gain a basic understanding of design theory, I mostly used Medium and Udemy. You can find links to the resources I used in the section below.

Build something

Any developer or CS professor will tell you that the best way to become a better programmer is to write code. The same principle applies to design.

It doesn’t matter what you design, as long as you learn from it. Treat it as a real project: Think about the users. Create wireframes, mockups, and prototypes. Iterate on the original design to improve it. You can use sites like Reddit to get feedback on what you create.

You can even pair it with improving your development skills. Most of my recent side projects have been motivated by a joint desire to improve both my web development and design skills. After you design your project, you can develop it and see both sides of the coin.

Here are some ideas to get you started:

• Design an interaction. Use Medium’s applause button for inspiration.
• Design an app for your favorite charity. Think about the different kinds of users: potential, infrequent, and regular patrons.
• Design your CV. Think about the colors you use and what the mean. Think about how your CV will be used. Will it just be viewed on a screen, or will it be printed out? How does that influence the design?
• Redesign an existing website. It could be your local transport provider or a global brand. Compare your design with the original and think about the differences from a user’s perspective.
• Design something physical, such as a new method of transport or maybe an alternative to something simple like a fork or chair. I have found thinking about the design of everyday things to be a really useful way of getting in the mindset to design something intuitive.

Don’t give up

When I look back on what I created a year ago, it’s hard not to wince. But everyone starts somewhere. Seeing the progression in what you create will be worth it. As long as you are learning from what you’re doing then your time is being well spent.

It might help to keep track of what you have learned at a regular interval. Every month I look back at some of the things I have worked on and try to take as much as I can from the experience. Even if it’s only to recognize some small piece of information you picked up from reading an article, it’s still progress.

Some designs I have created from oldest (left) to newest (right)

Resources

Below is a small collection of my favorite tools, articles, and courses. You can find many more that I haven’t listed here, and here.

Tools

Figma — Design and prototyping with collaboration.

FramerX — Similar to Figma, but with added React, and discoverable components.

Coolors — Discover and generate color palletes.

WebAIM Contrast Checker — Make sure your colors are accessible.

Archetype — Typography system editor and generator.

Articles

7 Practical Tips for Cheating at Design

10 cheat codes for designing User Interfaces

10 Small Design Mistakes We Still Make

Design Better Forms

A Complete List Of UX Deliverables

The Psychology Principles Every UI/UX Designer Needs to Know

How to use colors in UI Design

16 Quotes You Need to Read as UX Designer

Product Design Principles in a Single Card

Courses

User Experience Design Fundamentals — Udemy

The Complete App Design Course — UX, UI and Design Thinking — Udemy

UXTraining.com

Conclusion

I hope you have been able to take something from my journey. If you have design tips or resources that have helped you learn, I would love to hear them in the responses.

Thanks for reading!

The theme for week #6 of the Weekly Coding Challenge is:

Buttons

“A button? ?” you might ask… Yes! A button! ?

“But why?”

Because a button is one of the building blocks of any website/web application. Whether you are on Facebook or Twitter or Google, etc, you’ll always find a button that allows you to interact with the application in some way. So this week we’re going to build buttons — lots of buttons!

If you want to participate in the Challenge, feel free to build any kind of buttons: 3D buttons, buttons with ripple effect, animating buttons, etc — the sky is the limit ?. Be creative! You know how much I value creativity! ?

In this article we are going to build multiple buttons and put all of them in a Buttons UI Kit:

Before we move to the implementation part, let’s see the different states in which a button can be:

1. Default state
2. Hover state — when the mouse is over the button
3. Active state — when the button is pressed
4. Focus state — when the button is highlighted. Allowed on elements that accept keyboard events. This is used to give users that only use the keyboard some guidance as they traverse the application.
5. Disabled state

We need to style the buttons to cover all these states.

Also, we’ll have three different button types: primary, secondary and tertiary and two extra sizes: large and small.

The HTML

<div>
    <h4>Primary</h4>
    <button class="btn btn-primary">Default</button>
    <button class="btn btn-primary btn-hover">Hover</button>
    <button class="btn btn-primary" disabled>Disabled</button>
    <button class="btn btn-primary btn-large">Large</button>
    <button class="btn btn-primary btn-small">Small</button>

    <h4>Secondary</h4>
    <button class="btn btn-secondary">Default</button>
    <button class="btn btn-secondary btn-hover">Hover</button>
    <button class="btn btn-secondary" disabled>Disabled</button>
    <button class="btn btn-secondary btn-large">Large</button>
    <button class="btn btn-secondary btn-small">Small</button>

    <h4>Tertiary</h4>
    <button class="btn btn-tertiary">Default</button>
    <button class="btn btn-tertiary btn-hover">Hover</button>
    <button class="btn btn-tertiary" disabled>Disabled</button>
    <button class="btn btn-tertiary btn-large">Large</button>
    <button class="btn btn-tertiary btn-small">Small</button>
</div>

We are using classes to differentiate between the different types of buttons.

The CSS

.btn is the main class used by all of our buttons:

.btn {
    border-radius: 2px;
    border: 1px solid;
    color: #ffffff;
    cursor: pointer;
    font-family: 'Open Sans', sans-serif;
    font-size: 14px;
    padding: 8px 24px;
}

☝️ Some general styling to make it look better than the default version. ?

Next, we have the different states:

.btn-hover,
.btn:hover {
    opacity: 0.9;
}

.btn:disabled {
    background-color: transparent;
    cursor: not-allowed;
    opacity: 0.7;
}

.btn:active {
    opacity: 1;
}

.btn:focus {
    outline: 0;
}

In order to have some difference between the states, we can play with the opacity property.

Initially the button has opacity: 1 and we reduce that opacity slightly when we hover over the button and then a little more when the button is disabled. When we click on the button though, we'll set the opacity back to 1 as it gives a nice effect.

For the focus state, we remove the default outline property and we'll add a box-shadow property instead, but we'll do this separately for each button type because the color is changing depending on the class (see below).

The individual colors are set to the .btn-primary, .btn-secondary and .btn-tertiary classes:

.btn-primary {
    border-color: var(--primary-color);
    background-color: var(--primary-color);
}

.btn-primary:disabled {
    color: var(--primary-color);
}

.btn-primary:focus {
    box-shadow: 0 0 5px var(--primary-color);
}

.btn-secondary {
    border-color: var(--secondary-color);
    background-color: var(--secondary-color);
}

.btn-secondary:disabled {
    color: var(--secondary-color);
}

.btn-secondary:focus {
    box-shadow: 0 0 5px var(--secondary-color);
}

.btn-tertiary {
    border-color: var(--tertiary-color);
    background-color: var(--tertiary-color);
}

.btn-tertiary:disabled {
    color: var(--tertiary-color);
}

.btn-tertiary:focus {
    box-shadow: 0 0 5px var(--tertiary-color);
}

As you can see we use the CSS variables method to set the same color on different properties. But for this to work, we need to declare the color variables on :root as follows:

:root {
    --primary-color: #3457dc;
    --secondary-color: #ea4d67;
    --tertiary-color: #ea674d;
}

Note that it’s good practice to add the :root declaration in the top of the css file.

Lastly, let’s add the two extra sizes; .btn-large and .btn-small classes:

.btn-large {
    font-size: 16px;
    padding: 12px 36px;
}

.btn-small {
    font-size: 12px;
    padding: 4px 12px;
}

Conclusion

See how easy it is to create a Buttons UI Kit? ?

As a bonus features you can add a ripple effect to the buttons via JavaScript. I did this in a previous article - you can check it out by clicking here!

I hope you liked this challenge and I can’t wait to see what you’re going to create!

Happy Coding! ?

Originally published at www.florin-pop.com.

This one is for all the content creators out there who can’t afford to pay a professional designer, as well as for non-designers on a team where designers are always too busy to help. If you can follow these simple steps, I guarantee your designs will look better.

This list was born out of years of observing my non-designer friends, family and colleagues struggle with designing things they need in their everyday life. Personal newsletters, CVs and portfolios, pictures for posts on Facebook or Instagram, video thumbnails for YouTube and so on.

All of these people came to me for help and advice on how to make things look better. I’m a firm believer in the whole “teach a person to fish” idea, so rather than designing things FOR them, I tried to give them valuable advice that could help with similar issues in the future.

As time went on, I realised I’ve been giving people all the same tips over and over again. I have worded them differently each time, but all of my advice I can distill down to these four principles.

I am aware that there are thousands of lists just like this one out there, but I find these lists to be too excessive. You can’t really consistently follow a list of 25 “simple” (nothing containing 25 parts can be truly “simple”) steps as a non-designer. And you don’t have to.

Will this help you create shiny beautiful designs? No. Will this help you create great, clear and comprehensible designs that everyone can easily understand and interact with? Absolutely. So, without further ado, I present to you:

4 Fundamental Design Principles Anyone Can Follow To Achieve Great Results

Contrast

Make sure there is enough contrast between all elements.

Why? Because things that are slightly different, but not different enough, create a kind of Uncanny Valley. They feel eerie and repulsive to a human eye, and/or are difficult to comprehend. Now we don’t want that in our designs, do we?

Elements of your design should be either exactly the same, or significantly different.

Issues with contrast mostly manifest themselves in 4 different ways:

1. Colour: use dark on light colours and vice versa.

Example: Never use combinations like grey on a slightly darker grey or light pink on light blue — they are extremely difficult to read/interact with.

2. Size: only put elements next to each other that are either exactly the same size, or a considerably different size.

Example: Don’t put 32pt and 36pt text lines next to each other. 18pt and 36pt, on the other hand, will work great together.

3. Weight: same as with Size, only put elements next to each other that are either exactly the same weight, or a considerably different weight.

Example: Don’t put “Bold” and “Black” weights of the same typeface next to each other — because they look too similar. “Light” and “Bold” weights, on the other hand, will work great together.

4. Style: don’t put one italic type next to another italic type, or one serif typeface next to another serif typeface. Combine things that are different.

Example: Don’t put “Times New Roman” and “Georgia” next to each other — they look too similar. Combine fonts that have considerably different styles.

Consistency

Make sure similar elements appear in similar ways.

Why? First of all, by keeping things consistent (and, therefore, simple), you allow people to focus their attention on important aspects of your design rather than being distracted by things changing all the time.

Second, consistency increases trust and makes things look actually designed, rather than just quickly thrown together.

Things to stick to once you have selected them:

• Typeface/font
• Colour palette/shade of colour
• Grid
• Alignment
• Style of decorative elements

And so on...

_Placeholder text courtesy of [Batman Ipsum](http://batman-ipsum.com/" rel="noopener" target="blank" title=")

When you are working on many different pieces that appear next to each other (for example, video thumbnails for your YouTube channel, or covers for your Medium articles), choose one overall style for all of them and stick to it as well.

Occam’s Razor

aka Reduce Visual Noise

The fewer the number of elements you use in your design, the better.

Why? It’s hard for the human brain to process information and make decisions with an overload of input. Use as few decorative elements (typefaces, colours, shadows, frames, strokes, icons, patterns and so on) as possible.

Apply a design version of Occam’s Razor to everything:

If something can be achieved with just 2 elements, don’t use 3. If something can be achieved with 10 elements, don’t use 20. You get it.

_Placeholder text courtesy of [Batman Ipsum](http://batman-ipsum.com/" rel="noopener" target="blank" title=")

If you don’t like old English scholastic philosophers and prefer things you can see on Netflix, sure: be the Marie Kondo of your own designs. Whatever doesn’t spark joy (or isn’t a useful part of a design), has to go.

Space

The way things are positioned sends a meta-level message about their meaning.

Why is this important? Because minding how you position things and how much space you add around them helps reduce the complexity of a design, and, therefore, makes it both more pleasing to look at AND easier to interact with.

To use space in your design to convey meaning mind these 3 things:

1. Proximity = Relatedness

Things that are closer to each other than to the other elements, are perceived as being related more to each other than to the other elements.

This one is the most important because I feel like it’s being ignored too often (even by some people claiming to be professional designers, not to name any names).

It can be applied in many different ways, for example:

• There should be more space between the lines than between each word in a line — and, similarly, more space between different paragraphs than between the lines inside a paragraph.

• Elements of a design should have less space between each other than between those elements and the edges of the composition.

• Labels and supporting information should be positioned near the elements that they describe/relate to.

2. Negative Space

In combination with Occam’s Razor, give your designs as much negative space as you possibly can, to declutter them and make their meaning more obvious.

Putting too many elements into a limited amount of space is like trying to listen to three different songs at once. It’s hard to understand what is being said.

Look at Apple’s website. One can very clearly understand what is being said (or, rather, sold).

3. Importance and order

This one is extremely common sense but I feel like I still have to mention it here.

Things that matter most, you put first, and/or make them take up the most amount of space. Use sequences of things to convey order. Et cetera. You can definitely figure out the rest.

The End

Congrats! If you have followed all these steps while making whatever it is you are making, it most likely looks very good by the industry standards.

For everything else, there is always a designer.

My name is Mészáros Anna, I’m a graphic/UI designer turned UX/UI designer with an academic background in philosophy and interest in all things design ethics. I’d love to connect with more like-minded individuals, so feel free to drop me a message and follow me on either Medium or Twitter.

Angular is a great framework and can be used for developing large scale applications, but can be tricky to fine tune and achieve good load time and run-time performance. In this post, I’ll detail some best practices I have learned along the way, so you will not make the same mistakes I made.

Change detection

Change detection is Angular’s mechanism to see if there are any values that have been changed and require the view to be updated. By default, Angular runs change detection with nearly every user interaction. In order to know if the view should be rendered again, Angular accesses the new updated value, compares it with the old one and makes the decision. As your application grows, it will include a lot of expressions, and having a change detection cycle on each one of them will cause a performance problem.

We can optimize things if we create a ‘dumb’ component with a certain attribute to handle the change detection cycles. This component relies only on non specific input data and in that way, we can tell Angular only to run change detection when an input changes or when we manually trigger it. When a reference type is immutable, every time the object is being updated, the reference on the stack memory will have to change. Now we can have a simple reference check on the object between the memory address and the stack. If the memory address has changed, then we check all the values. This will skip change detection in that component.

We need to keep in mind that primitive types such as numbers, booleans, strings, etc are passed by value. Objects, arrays and functions are also passed by value, but the value is a copy of a reference.

You can look for more details on that here.

And now we will see two examples of how this is implemented.

Example: ChangeDetectionStrategy.Default

You don’t have to specify changeDetection type, it will be ‘ChangeDetectionStrategy.Default’ by default.

Default change detection

_Photo by [Unsplash](https://unsplash.com/@timmossholder?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Tim Mossholder on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

ChangeDetectionStrategy.OnPush

In order to use the OnPush change detection, we need to modify the child component from the first example.

OnPush change detection

Minimize DOM manipulations

If you have some list of data that was retrieved from some server and you need to show it, you are probably using the Angular directive, ngFor. Angular will create a new template for you for each item in that list.

If at some point some of the data has been changed, Angular can’t really know that and will replace the whole list, instead of just the items that were changed. In order to improve that, Angular provide us with the trackBy function.trackBy takes a function which has two arguments: index and [item](https://angular.io/api/core/IterableChangeRecord#item). If trackBy is given, Angular tracks changes by the return value of the function.

Syntax:

Most common use is just to return the index itself or item.id as a unique identifier for the item: trackByFn(index, item){ return item.id; }.

With that, Angular can track which items have been added or removed according to the unique identifier and create or destroy only the things that were changed.

Avoid using methods in your template

While it is very convenient to use methods in Angular templates, Angular will recalculate them on each change detection. For larger lists it will affect rendering time and the application may even get stuck due to huge memory consumption. In the following example, Angular will run getNumberOfCars on each change detection cycle (ie upon adding a new row).

How can we handle this situation? We can pre-compute the results and then just access the data we have computed. In our example, we can add a new attribute to the person object, vehiclesNumber, which holds in advance the amount of vehicles each person has. The other way to do this is by implementing the method getNumberOfCars as a pure pipe.

According to Angular pipe documentation:

Angular executes a pure pipe only when it detects a pure change to the input value. A pure change is either a change to a primitive input value (String, Number, Boolean, Symbol) or a changed object reference (Date, Array, Function, Object).

Angular ignores changes within (composite) objects.

This may seem restrictive but it’s also fast. An object reference check is fast — much faster than a deep check for differences — so Angular can quickly determine if it can skip both the pipe execution and a view update.

The pipe will still be executed on each change detection cycle. However, if a pipe is executed more than once with the same parameters, the results of the first execution are returned. Meaning, Angular will cache the results for better performance.

Let’s see an example.

Without a pipe:

While with a pipe we will get:

We can see it will recalculate only on the new data, instead of the whole list.

Use Prod flag in production

It will disable Angular’s development mode, which turns off assertions and other checks within the framework. This will also increase your performance. You can find more details here.

Don’t use console.log in production code

console.log prints can really slow down your application, as it takes some time to compute what you want to print. Also, for long information it will also consume some more time for the printing process.

Don’t forget to unsubscribe from your observables

Your subscription holds a reference to your component instance. If you will not unsubscribe from it, the instance will not be cleared by the garbage collector which will cause a memory leak. You can unsubscribe easily by using ngOnDestory(){this.subscription.unsubscribe();}. You can read more about it here.

Final Words

If you run into any issues, feel free to drop me a line at : markgrichanik[at]gmail[dot]com.

I would also love to hear any feedback/tips you have while working on large scale applications with Angular.

If you liked this article, ? away so that others can read it as well