Why?

Because users rarely care about features. They care about getting things done. They care about outcomes.

If you were to announce any of these updates:

• An AI search feature was added.

• Dark mode is now available.

• We've launched a new dashboard.

These sound exciting, but mainly to the person/team that built them, they don't mean much to users on their own.

What users really want is to:

• Find what they're looking for faster.

• Better understand their business.

• Save time and complete their tasks faster and easier.

A feature is only valuable if it creates a meaningful outcome. That's why I try to build (and sell) outcomes, not features. So whenever I'm building something, I ask myself:

What outcome does this feature create? Which user goal does it help achieve?

If I can't answer these questions clearly, it's usually a sign that the feature needs more thought.

As AI makes product development even easier, the focus has changed from just writing code. The builders who stand out and get the most out of products will be those who combine product thinking, design, engineering and AI to solve real problems.

Next week, I'll share how applying this outcome-based approach increased how users engage in one of the products I'm currently building.

See you next time!

I'm Mary, a product engineer, who designs and builds usable, accessible and intelligent products

1. Confusing 'Account Setup' with 'Onboarding': Your onboarding flow is meant to serve a primary purpose, which is to show the user why your product matters; lead users to their first 'Aha' moment. This is about discovering the value of your product and how it applies to them, more precisely, how it provides a solution to their pain point. We often think onboarding is for us (the product owners); to get the data we need for the product's functionality, but in reality, onboarding is for the user. Data collection for very critical functionalities is important but it should never replace the primary reason of why the onboarding flow exists in the first place. Every piece of information you ask for should try in making them see the value of your product. If asking for their 'Company Size' doesn't immediately change what they see on their dashboard, don't ask for it...yet. And in some cases, if done well, some parts of onboarding could also be used to collect critical setup data. But value must come before asking, helping your users understand the 'why' of your product would encourage them to provide their 'what'. In addition to this, the 'why' should also not be left out during data collection. Helping users understand why they need to provide their information also builds trust. Let’s look at a real-world example of a product that does this well.

   Sample Product: Duolingo
   The User's Pain Point: The intimidating feeling that learning a new language is too hard or will take years.
   The "Aha!" Moment: Realizing they can translate a complete sentence in a foreign language in less than 60 seconds (this would excite any new learner)
   How Duolingo shows value during onboarding: Instead of starting with even a "Create Account" screen or asking for your name and email, Duolingo drops you straight into the product:
   - Choose Your Goal: The user immediately selects what they want to achieve (e.g., "Spanish for Travel").
   - The Interactive Lesson: The user is immediately placed in a mini-lesson. They click buttons, hear audio, and solve puzzles. Some infornation gotten includes the "Technical Setup" introduced as a game.
   - The "Aha!" Moment: After 5-10 screens, the user has earned their first win and realized that they can 'do it'.
   - The Delayed Setup: Only after a user has finished the lesson and felt the win does Duolingo ask them to 'set up' - save progress by creating an account.

   

   Now, imagine what this would have felt like if Duolingo started with a 10-field registration form and a "Verify Your Email" requirement, most users would lose interest before they ever learned a single word. The onboarding flow led with the solution and providing value (in this case it was learning) before earning the right to ask for the data (the account).

   While this approach is harder to build (because you have to manage temporary "guest" states in your database or client side), the payoff in user conversion is almost always worth the engineering effort.

2. Feature Overloading: It's easy to feel like having a lot of features increases the value of a product, but this isn't so, because more features would mean higher cognitive load and more friction points for the user. With feature overload, users would have to use more mental energy to navigate the product interface than actually achieving their core goals. It specifically hurts the product by trigerring decision paralysis. They become overwhelmed and confused about 'what to click on', 'what to click first', etc. This isn't a coincidence but an actual phsychological principle, Hick's Law, which states that the more choices you present, the longer it takes for a user to make a decision. This in turn affects the product learning curve, making it a lot steeper because of feature clutter. It also further buries the main purpose of the app, the core value proposition that keeps them coming back. And if there are more chances for users to face friction points then there would also be high drop offs out of frustration. To fix this issue, it is important to ensure that the core functionalities of the the product are easy to access and priortised in the user flow. Patterns like progressive disclosure could be adopted to handle secondary features in sub-menus, internal pages, modals, accordions, etc where they would not be competing for the user's attention.

   The design below shows menu and hamburger, an example of progressive disclosure. Design by Nicholas Ergenia

   

3. Skipping Usability Testing: Usability testing is commonly ignored and this shouldn't be so. Apart from the usual functional testing (which checks if the product works), you still need to test how usable your product is. Usability testing involves observing how real users interact with your product as they try to complete specific user tasks. It checks if the user can actually navigate and use the solution you’ve built. It shows where users get confused, where they hesitate, and where your assumptions about their behavior don't match reality. It also helps to validate the 'Aha' moment, whether it is reachable or if users are getting stuck on unnecessary friction points that you might not notice. The good thing about usability testing is that you can start small with about just 5 people, this usually leads to dicovering about 80% of usability issues. Skipping usability testing makes a large number of your users unknowingly test your app, but instead of reporting an issue as a bug, they totally stop using the product.

Follow me for more!
Hi, I'm Mary, i'm a design engineer, who designs and builds usable, accessible and intelligent products

The Cognitive Friction of the Modern Web

I did some research and tried to better understand the major barriers these users face. The common observation was these:

• ADHD and Sensory Overload: For users with ADHD, using a typical website might feel like trying to read when 3 people are shouting 3 different things at you. Auto-playing videos, promo and consent popups, and cluttered layouts create a kind of 'noise' that makes it nearly impossible to focus.

• Dyslexia and Visual Stress: Users with dyslexia often describe large blocks of text as 'swimming' in their faces or blurry. Long sentences with complex words make it really hard to retain the meaning of the sentence by the time they reach the end.

An Experimental Solution

I built this product to explore how AI could be beneficial in making the web more accessible, in ways we might have never thought of. It acts as a bridge, reducing cognitive stress by simplifying language and reducing digital clutter. Because this is a Chrome Extension built on Chrome’s built-in AI, the processing happens directly on the user's device. This project focused on two main functions:

• Simplification: Rewriting complex jargon into plain, accessible language.

• Action Item Extraction: Surfacing "Action Items" (like deadlines or very important information) so users don’t have to hunt through 1,000 words of copy to find them.

Solving the "Privacy Tax"

Building this project helped me see a much bigger picture regarding AI and ethics. For a user with a cognitive disability, using most AI tools would mean that they have no privacy anymore to even do something as basic as using the web because they often have to expose their private browsing data just to make a website readable. By building Clarity Lens as an extension using local, built-in AI; this privacy tax is eliminated because their data never leaves their browser.

This project showed that we can build AI-enabled products that are both deeply accessible and private by design, ensuring the web remains a place where everyone can navigate with dignity and ease.

Follow me for more!
Hi, I'm Mary, i'm a design engineer, who designs and builds products

Is this AI or magic?

Beyond the obvious chatbots and fancy AI assistants we interact with, one way to detect that an interface is AI powered is how it responds to the user, it's smart. When you open an app and it already seems to know what you want, that’s the feeling of “smartness” and it shows up in different ways.

🔍 It’s in the search bar that completes your thought before you finish typing.
✉️ The email app that suggests a sentence you were just about to write.
🎶 And the music app that builds a playlist that actually fits your mood.

These experiences that feel 'just right', are a result of AI models learning patterns and adapting to the user or current context. What feels smart is most times a mix or one of the following:

1. Anticipation : when the system predicts your next move. e.g Gmail’s Smart Compose automatically suggests full sentences as you type, often matching your tone. The interface isn’t waiting for instructions, it’s predicting your next action in real time.

2. Personalization : when it adapts based on your behavior, preferences or context. e,g. Instagram reshapes your Explore page based on what you pause on, repeat or interact with, not just what you like, quietly learning what holds your attention.

3. Efficiency : when it reduces friction without asking you to explain yourself e.g Google Maps rerouting automatically when there's traffic ahead, without asking whether you want an alternative.

4. Relevance : when results or suggestions feel tailored and timely e.g Spotify’s “Daylist” changing throughout the day based on time, your listening habits, and context.

Most times, these interactions are not viewed as AI because they are quiet and don't show up as a chatbot or AI assistant would. But they are, and they tend to feel most natural because intelligence is neatly woven into the experience, yet deeply influencing user behaviour.

In everyday digital experiences, AI isn’t just a smart chatbot, it’s the quiet intelligence behind the scenes that makes interfaces feel smart, intuitive, and personal. So next time you use an app and you notice any of these things, try to think about how the design and architecture decisions behind the application, this would give a better understanding how AI works and is used on the UI. As AI continues to evolve, the boundary between what’s obviously algorithm-based and what feels more natural will only blur further, underscoring how deeply AI is woven into the interfaces we use every day.

Resources

• https://www.toptal.com/designers/product-design/anticipatory-design-how-to-create-magical-user-experiences
• https://globalresearchandinnovationpublications.com/HCI/article/view/74

While modern CSS provides the visual and structural foundation for carousels, a semantic JavaScript "patch" might still be necessary today to fulfill critical Web Content Accessibility Guidelines (WCAG) requirements. It would ensure that cross-browser compatibility, focus management, and other kinds of accessibility-related issues are handled for all users. We'll be looking some more into these issues in this article.

The Power and Limitations of Pure CSS: How Do CSS-Only Carousels Even Work?

The way CSS carousel works hinges on these features: the scroll-snap-type, scroll-snap-align and the overflow-x. As you would likely know, the overflow property is used to control how content is handled when it exceeds the boundaries of its containing element. In this case, it is used to enable scrolling when set to scroll, so that hidden carousel slides can be exposed by horizantally scrolling. This also means that slides which are not currently in view are "off" the screen, but still exist. This article gives a detailed overview of how CSS-only carousels work: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_overflow/CSS_carousels

The CSS Scroll Snap Module , allows the creation of smooth carousels that “snap” perfectly into place as users scroll. This is done accurately and purely without JavaScript. This is possible because scroll-snap effectively assigns the complex behavior of the carousel to the browser's own scrolling engine, which is faster and more efficient.

The scroll-snap-type goes on the parent element (the carousel wrapper) that holds all the individual slides. It tells the browser that this element is a scroll container and it should utilize the snap behavior. On the other hand, the child elements (the individual slides) are tagged with the scroll-snap-align property. It specifies where on the slide the snap should align relative to the container/wrapper. So, when the user lifts their finger or releases the mouse, the browser automatically calculates the nearest center alignment point. The browser then uses a smooth, hardware-accelerated scroll to accurately land on that point, ensuring only one slide is fully visible and perfectly centered, copying the behavior of a traditional JavaScript carousel.

But here's the thing:

Building a CSS-only carousel like this can create a very frustrating user experience to users who use Assistive Technologies (AT), even though everything appears smooth on the surface. This brings us to the next part of this article.

The Semantic Gaps: Where CSS Falls Silent

1. The first we'll look at is Focus Traps: The ATs and the browser itself which controls the snapping still typically see and recognize off-screen content as part of the page's document order. Screen readers and keyboard users would still be able to tab to an interactive element (like a button or link) that is visually off-screen, creating a frustrating experience known as a "focus trap" issue. This is against the WCAG 2.4.3 (Focus Order) accessibilty guideline. Further going a bit deeper, we also see that this is where the HTML inert property comes in. It puts elements in an 'inert' state. The inert property tries to manage focus and interaction for off-screen content. It does this by:

   • Interaction Blocking: It prevents hidden elements from being unintentionally activated using mouse clicks or other input methods.

   • Accessibility Tree Noise: It removes off-screen content from the accessibility tree, preventing screen readers from announcing content the user can't see.

How JS fixes this: By dynamically applying inert to off-screen slides, keyboard users cannot tab into invisible elements, this helps to maintain a logical focus order for visible elements. One common method used is the combination of IntersectionObserver + inert.

2. Inability to Update ARIA Live Regions: CSS cannot dynamically update the DOM or trigger programmatic announcements. This is a significant technical limitation. It cannot alter the HTML structure, modify ARIA attributes, or intercept and control user input (like keyboard presses) to provide the necessary semantic information and interaction required by WCAG (Web Content Accessibility Guidelines). This is against the WCAG 4.1.2 (Name, Role, Value) and the lack of programmatic context for screen reader users. This is fundamental because it requires that for all user interface components (including hidden states, like a slide changing), the name and role can be programmatically determined, and that changes in these items are announced to the user. For example:

   A change happens when the carousel slides from one image slide to the next. This is a crucial change in "value" (the content currently being displayed). There needs to be an announcement like "Image Slide X of Y" when this change occurs, but it fails because the state change is managed solely by visual scrolling in CSS, so the browser does not recognize a programmatic change to announce.

   The JS Solution: This solution uses an IntersectionObserver to detect the exact moment a slide comes into view, this would then trigger the script to manually update a visually-hidden, aria-live="polite" element with the current position (e.g., "Slide 3 of 5"). This forces the screen reader to announce the state change, fulfilling the communication requirement of WCAG 4.1.2.

3. The Missing Pause/Stop Functionality: This is a non-visual requirement. If the carousel automatically rotates or moves, CSS cannot provide a control to stop the animation. This goes against the WCAG 2.2.2: (Pause, Stop, Hide) accessibility requirement.

   How JS Fixes this: A single line of JS to toggle the CSS animation-play-state property and also update the button's aria-label (e.g., from "Pause Slideshow" to "Play Slideshow").

4. Incorrect ARIA Role (Semantic Mismatch) : Another major issue as pointed out by Sara Soueidan is incorrect ARIA Role which happens because the Browser exposes Carousel UI elements as ARIA "Tabs" and "Tablist". The scroll markers become role="tab".

   What this means is that the browser sees interactive scroll markers and makes a faulty assumption based on existing ARIA patterns (tabs, buttons, links). It defaults to the tablist pattern, which is wrong for a simple image carousel or gallery.

   The JS Solution: JS is required to override the browser's guess by adding clear ARIA roles (e.g., role="group", aria-roledescription="carousel").

Conclusion

So far, we see how CSS only carousels are not fully usable and might need the semantic JS fixes to properly cater for every user. It fails some important usability and accessibility checks.

The reality is that CSS is a styling engine, not a semantic language. When a carousel is created using CSS features like overflow-x and scroll-snap-type, we achieve a powerful visual component. However, the component is still semantically and functionally incomplete for assistive technology users. The browser simply cannot be relied on to correctly handle complex interactive requirements like focus management across hidden slides, programmatic announcement of state changes, etc

The use of JavaScript is not just a fix neither is it a failure of CSS; it is a good semantic patch that closes the gap between usability, performance and compliance.

This hybrid model shows how CSS dictates the motion and performance, while a few lines of JavaScript would help with the critical accessibility requirements for a carousel.

References:

• https://www.w3.org/TR/css-scroll-snap-1/#overview
• https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll_snap/Basic_concepts
• https://www.w3.org/TR/css-scroll-snap-1/#overview
• https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/inert
• https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
• The proposed CSS inert property
• https://developer.mozilla.org/en-US/docs/Web/CSS/::scroll-marker

I don't just see design tokens as the bridge between design and code, tokens are the foundation of that bridge, it's the system that makes building the bridge even possible.

The impact of design tokens in the product development today are huge and fundamentally changes how design systems scale and how designers and developers work together. At the core, design tokens are the atomic design decisions of any system, it is made up of the color values, spacing units, typography scales, etc stored as data rather than scattered across stylesheets, code and design files.

This is one of those terms that sound really abstract, but that in itself is exactly where it’s power lies, its abstraction. I like to think of it like this: Instead of hardcoding #3B82F6 throughout my codebase, I define a token like color.primary.500.

This really simple action creates a single source of truth that can be referenced by both designers and developers. If your primary color value needs updating, you simply change one value, and the entire system updates automatically across every platform and implementation.

These are some important things to know about design tokens:

1. Design tokens follow a clear naming standard, which is based on the 3 types - the Primitive, Semantic and Component tokens.

2. Based on type of design property, tokens are usually organized into several categories, some major categories are: color tokens, spacing tokens, typography tokens, border tokens, shadow tokens, motion tokens, etc.

3. Major design systems like Material Design, Shopify’s Polaris , Atlassian Design System rely heavily on tokens

4. Design tokens are not dependent on languages or plaforms they are used in. Tokens are defined once in a neutral format (usually JSON), then used in any target platform e.g CSS variables, React.js, iOS Swift code, React Native, etc. This means your iOS app, web application, and Android app can all reference the exact same design token, and therefore have the same result, ensuring true cross-platform consistency.

5. Design tokens were originally created by the Salesforce design system team.

6. I really do see tokens as a fundamental part of AI-driven design-development workflow.

7. The W3C is working on standardizing token formats. Check out the community group here

Some of which are:

1. Transitioning heavy properties - Animating properties like width, height, or left can cause serious performace issues. This happens because they trigger a repaint operation which is heavy. On the other hand, properties like transform and opacity should be used. The reason is because the latter properties use GPU processing which is optimized for rendering graphics-heavy properties.
2. Not using will-change as it should be used - The will-change CSS property can be used to improve the performance of animations and transitions, especially when working with complex filters, etc, but it should be used carefully as using it everywhere can waste memory resources and cause lags.
3. Animating box-shadow - Animating box-shadow will hurt performance, but you can create the same effect with the smallest repaint operations by animating the opacity of a pseudo-element. This would help achieve smoother animations.
4. Using transition: all - The transition: all animates every property that can change, and you can imagine what this would do to any UI, especially if there are so many animations implemented. Transitioning should be directly set and applied to the specific elements.
5. Too many transitions all happening at the same time - Running a lot of transitions at once and at the same time can cause hanging on the UI, particularly on devices that are not built to handle heavy processing.
6. Animating during heavy JavaScript execution - Transitions clashing with heavy DOM manipulation done by JS can cause dragging animations.

References:

• CSS-Tricks: "Animate box-shadow with Silky Smooth Performance" CSS-Tricks
• DEV Community: "Costly CSS Properties and How to Optimize Them"
• LambdaTest: "Boosting Web Performance With CSS GPU Acceleration"

Some top strategies to improve perception are:

1. Immediate Feedback (The 100ms Rule) - Make the system acknowledge the user's input immediately, even before processing starts. An example is when a user clicks a button, the button should visually darken or depress within 100ms. This instantly tells the user, "My click was registered," which prevents them from clicking again or thinking the app is frozen.

2. Illusion of Progress (Loading state) - Add loading states because filled time is perceived as shorter than empty time. Provide constant visual updates so the user is in an active state (watching progress) rather than a passive/paused state (just waiting). Examples of this are:

   • Skeleton Screens: Showing the outline of the content (like gray boxes) as it loads. This makes the user feel the content is already there and just "filling in."

   • Progress Bars: Bars that move smoothly and even accelerate slightly toward the end are perceived as faster than bars that move erratically.

   • Loading Spinners: Used for short waits (less than a second). For longer waits, they should be accompanied by explanatory text.

3. Load Critical Content first - Prioritize what the user came for, making the interface usable before it's fully loaded. A good example of this can be illustrated with what happens on a news site, the main article text and key navigation links load first, while high-resolution images or ads load in the background. The page appears "done" to the user much sooner.

4. Non-Linear Loading & Background Tasks - Pre-emptively load or calculate data for the next likely action the user will take. An example of this is when a checkout page loads the shipping options while the user is still typing their address. The transition to the next step feels instant because the data is already ready.

References

• Designing and Engineering Time: The Psychology of Time Perception in Software Book

This article explores how color in UI shapes behavior, trust, urgency, and even perception of quality.

Why colors feel the way they do

Imagine if traffic lights had green stop signs and red go signs. Would they still work?

While the meaning might change if we collectively decided it did, the instinctive reaction would be difficult to override due to learned associations.

Through nature, color instinctively guides us. We know that plants, forests and vegetation are green in color and this is psychologically interpreted as calmness, renewal, and stability because this is how we feel when we sight these things. Same goes for red, which is pyshcologically interpreted as danger because it shows up in blood and fire. On the UI, these associations guide everything from CTA colors to warnings, because you're not just styling a button, you're signaling a behaviour. A good example of how color has feelings is basically how most people feel on rainy days vs. how they feel on a bright and sunny day. This chart below shows a summary of some common colors and their association.

Image from Fifteen Designs

Cultural Nuances in Color Perception

On the flip side, color perception isn’t global, due to cultural associations. An instance is the color red, which means luck in China, but danger in the US and a lot of other places. This article by Chris Lee further verifies this, it says that in the US, declining stock prices are reflected with red color but in China, Korea, and Japan, rising stock prices are indicated in red because it is associated with wealth and stock gains. This shows how important it is to consider cultural perceptions because it determines what a user primarily feels based on their environment (what comes naturally to them). This is a very essential factor to consider especially when building for global and diverse audiences. This is the reason why McDonald's uses green in Europe but red in the US. To signal environmental consciousness and align with eco-friendly values more prominent in European markets. Their websites and app themes also adopted more earth tones and minimalism in these regions. Watch this video to learn more. Another example is Airbnb, which localizes colors and imagery on landing pages and mobile app UIs to reflect regional architecture, mood, and cultural color associations. Airbnb uses a primary color, #FF5A5F (a shade of pink), which represents openness, inclusivity, and community. Beyond the global color, Airbnb incorporates local color palettes inspired by the unique cultural and natural elements of each location. They also have a secondary palette featuring bold shades of purple and teal, named after and inspired by streets in cities around the world, further supports the brand's values and adds a local touch, according to The Branding Journal. In Middle Eastern markets, palettes may feature deeper jewel tones or sandy neutrals compared to pastel-heavy Western versions, because of the historical use of jewel tones and association with desert landscapes for sandy neutrals.

But here’s the thing, color in itself alone doesn’t carry meaning. A red can feel urgent or elegant. A blue can feel trustworthy or playful. What determines it's true meaning is how that color is tuned.

Tuning Color for Trust, Urgency & Emotional Clarity

Color properties such as hue, brightness, contrast and saturation affect tone, hierarchy, and usability on the UI. This is a major piece that connects the user's emotions, color perception and how colors are properly used on the interface. It also gives color it's true meaning.

For instance as shown in the image below, Spotify leans heavily into vibrant green and black to create an energetic and expressive feel. The green does more than brand the interface, it cues action and creativity. Its contrast against the dark UI and immersive images and videos, making the interface feel modern, expressive, and tuned in to a younger, music-loving audience. This use of color not only reinforces Spotify's brand voice but also helps users navigate intuitively.

So now, what is hue, saturation, brightness and contrast and how do these things affect the user experience? Well, these are fundamental properties of color and understanding them gives you powerful control over how color works in UI. So here's what they each mean and do:

1. Hue: This is what we typically think of as “color”, red, blue, yellow, green, etc and changing this means changing the base color.

2. Saturation: This refers to how intense or pure the color is. High saturation would give vivid, bold, vibrant colors while low saturation gives off muted, soft, grayscale-ish version of the same hue. In the UI, a highly saturated color is attention-grabbing (useful for CTAs or alerts), while a low saturated version of the same hue is calm and subtle (good for backgrounds, secondary UI). An easy way to define saturation is that it is how much gray is mixed in.

3. Brightness: This is basically how light or dark a color is. A color with high brightness is closer is to white and a color is low brightness is closer to black. A tint of a color is how much white is mixed in while a shade of the same color is how much black is mixed in

4. Contrast: This refers to the relationship between two or more colors. It’s about how a particular color stands out against something else or another color. It shows how a saturated yellow might have low contrast on a white background because the brightness levels are close but a low-saturation blue on a black background might have high contrast because of brightness difference.

It's important to understand how these color properties work together and the effect on the UI. How these affect things like: CTA visibility, error state perception and brand tone.

💡One tip is this: Don’t just choose colors, adjust their intensity, brightness and contrast based on the screen context and use case.

Still using Spotify as an example, we see how the primary color which is green is used for interface elements. It shows how button states using the same primary color but now a tinted version for the disabled state and a shaded version for pressed and hover states, all bring meaning to an interface and properly guide the user.

Image from Figma's Blog

Using Colors Strategically on the UI

So far, we’ve taken a look at how emotional psychology, cultural environment and color properties can affect color choices on the UI. I have curated a checklist of things to consider when dealing with colors on the UI.

• What action or message is this color supposed to show? A confirm action needs trust or clarity (e.g., green/blue), while a warning needs urgency (e.g., red/orange).

• Is this color already associated with a meaning in my product, platform or generally? Like the example of the traffic light given, users subconsciously have expectations (e.g., red always means “error”). Breaking it causes confusion.

• Will this color stand out in its context? A “primary” button shouldn’t blend into the background. Contrast and visual hierarchy matter.

• Is it accessible (sufficient contrast)? No matter how nice it looks, if it fails contrast, it fails function especially for users with visual impairments.

• Does this align with the brand voice or tone? A financial app using playful colors may feel unserious. A children's app using deep navy blue as the primary color may feel cold.

• How will this color behave in light vs dark mode? Some hues (like yellow or pale orange) lose their visibility or richness when flipped into dark mode.

• Is the color communicating a state? Hover, disabled, active, focus, error, success, etc. often require slight tone, brightness or saturation shifts. In fact, a quick color tactic is this: Use tints for gentle backgrounds or soft states, use shades for depth, hover, or dark mode and use saturation shifts for subtle hierarchy or to create "inactive" or "disabled" states (e.g., grayed-out buttons)

Passing Color Decisions to UI Development

Intentional color decisions in Figma is important, but if this is not held up in the code, users won’t feel the difference. Color is more than visual, it is behavioral, emotional, and functional. This is why developers play a critical role in making sure those color choices aren’t lost in translation. Use the checklist below to ensure that your interface honors the intention behind each color, not just visually, but functionally, accessibly, and at scale.

• Is the color token semantically named? Colors should be named based on their functionality on the interface e.g. primary, info, danger, surface-muted, avoid using color names alone e.g blue-1, blue-3. This helps to avoid inconsistent usage across dev and design and also matches how colors are meant to feel, not just look.

• Have all interaction states been accounted for? Developers tend to skip or misuse interaction states like the active or hover state of a button which are usually differentiated with color by using shades or tints. These states are important because they give users a visual feedback, it helps them know what's clickable or interactive and if they have interacted with it

• Is the color used consistently across states? Accounting for interactive states is not enough, states should be clearly defined in your palette e.g., --color-primary-hover, --color-disabled-text. This ensures consistency in user experience.

• Does this color choice affect perception (trust, urgency, etc.)? A blue alert that says 'Something went wrong' is wrong color choice as it doesn't give the user the right perception of an action they have taken on the UI which failed. Things like this are very important and the right colors in the right shades or tints should be used.

• Has this color been tested in both light and dark modes? A color might look really good in light mode but is hard to see in dark mode. And yes, the UI design might only be done for light mode interfaces, but users still have the freedom to change to dark mode using system or OS settings. If both modes are not properly tested and accounted for, it could greatly impact user experience for a specific set of people.

Conclusion

So far we've gone over why color feels the way it does, cultural nuances that could impact color perception, and how this translates to colors on the interface.

Color on the UI is about clarity. It helps users make decisions, feel trust, notice urgency, and navigate confidently often at a quick glance and without reading a single word.

That’s why designing with color isn’t just about picking beautiful palettes, it’s mainly about making intentional, context-aware choices that help elevate the UX, scale across themes, and hold up under accessibility standards.

Thoughtful color is a form of communication. The more deliberate you are, the more intuitive the experience becomes.

Useful Resources:

1. A long list of colors, their meaning, how they can be combined and used on the UI: https://www.figma.com/colors/

2. Find the color of anything: https://picular.co/

3. A one-of-a-kind tool for creating, managing, and sharing accessible color systems for user interface design: https://leonardocolor.io/

4. A Figma plugin to generate color palettes within Figma https://www.figma.com/community/plugin/1286792998372727741/color-wheel-palette-generator

5. A Figma plugin for creating color palettes based on Design Systems like Material, Atlassian, Orbit and Ant Design: https://www.figma.com/community/plugin/1024452006068794933/foundation-color-generator

6. A tool to create beautiful color palettes with AI. Generate color palettes from names, images, text, or hex codes https://colormagic.app/

7. A Figma plugin crafted to automate color and button creation: https://www.figma.com/community/plugin/1344368111040867237/design-system-generator

References:

https://www.figma.com/resource-library/color-combinations/

Useful for: Anyone who wants to level up their CSS layout skills (flexbox and grids)

This website is all about helping developers get better at CSS layouts in a fun, hands-on way. It’s like a playground where you can practice using CSS Grid and Flexbox to create cool, responsive layouts. You write code, see the results instantly, and tackle challenges that mimic real-world layout problems and whether you’re just starting out or brushing up on your skills, it’s a great way to learn by doing.

2. CSS Clip path generator: https://bennettfeely.com/clippy/

Useful for: Getting quick and clean clip-path CSS code.

This website is for creating cool shapes on the web. Made by Bennett Feely, this tool lets you easily generate CSS clip-path code for all kinds of shapes—polygons, circles, stars, and more. Instead of struggling with complex code, you can just tweak a few settings, copy the code, and voilà! You’ve got a unique shape ready to use in your design.

3. CSS Backgrounds https://superdesigner.co/tools/css-backgrounds

Useful for: Adding quick background patterns to the UI.

This website contains a collection of over 100 free pattern backgrounds created using CSS, these patterns can be used to add textures to hero sections, as background layers/overlays, used in the footer design or hover effects for creating beautiful CSS backgrounds. It’s part of the Super Designer toolkit and makes it really easy to customize the patterns and textures—all with just a few clicks. You can play around with colors, and styles to create something truly unique, and you get the clean CSS code ready to use in your project.

4. Grid garden: https://cssgridgarden.com/

Useful for: Beginners who want to learn more about CSS Grids

This website is a playful and interactive way to learn CSS Grid. Created by Thomas Park , it turns CSS grids into a game where you grow a garden by the code. Each level introduces new concepts, like aligning plants or watering specific plots, making it a fun and engaging way to get comfortable with CSS Grid.

5. Typescale: https://typescale.com/

Useful for: Designers and developers who want to ensure their typography is balanced and professional.

This website is a great tool for creating balanced and visually appealing typography scales for your projects. It allows you to experiment with different font sizes, ratios, and scales (like the golden ratio, perfect fifth, or modular scale) to find the perfect typography hierarchy. You can preview how your text will look, adjust settings, and get the corresponding CSS code to implement it seamlessly into your website.

6. Keyframes: https://keyframes.app/animate

Useful for: Creating CSS animations to add to your websites

This website is like a shortcut for creating smooth CSS animations. It’s super easy to use—just tweak settings like timing, easing, and movement, and it spits out clean CSS code for you. Whether you’re adding a subtle hover effect or a full-blown animation, this tool makes it really easy.

7. Haikei App: https://haikei.app/

Useful for: Modifying unique patterns & visuals to add to the user interface.

This is a very useful tool for generating unique, customizable SVG shapes, blobs, waves, and other design elements. It’s perfect for adding visual flair to your projects. With a simple interface, you can tweak colors, shapes, and patterns, and then download the assets as SVG or PNG files. Whether you need a background, a divider, or a decorative element, Haikei makes it quick and easy to create something eye-catching.

8. CSS loaders: https://css-loaders.com/

Useful for: Getting simple loading animations.

This is a handy resource for finding and customizing simple, ready-to-use CSS loading animations. It offers a wide variety of pre-built loaders, from simple spinners to more complex animations, all made with pure CSS. You can preview the animations, tweak the code, and easily copy it into your project to keep users engaged while content loads.

9. Pure CSS Icons: https://css.gg/

Useful for: Adding scalable icons to projects without the hassle of managing image files or external libraries. It’s perfect for anyone looking for a lightweight, customizable icon solution.

This is a minimalist icon library built entirely with CSS. It offers over 700 customizable, open-source icons that are lightweight and easy to use in your projects. Each icon is designed with pure CSS, meaning no images or external dependencies are required. You can easily copy the code, adjust the size and color, and integrate the icons seamlessly into your website or app.

10. CSS filters: https://www.cssfilters.co/

Useful for: Applying and testing cool effects to images using CSS filters.

This is a visual playground for experimenting with CSS filter effects. It lets you apply and customize filters like blur, grayscale, brightness, and contrast directly on an image, showing the results in real time. Once you’ve tweaked the effects to your liking, you can grab the CSS code and use it in your own projects. It’s a simple and fun way to add creative touches to your images without needing any design software.

Thanks for reading! ⭐

I hope you found this list helpful! You can bookmark and share with others. If you have any other CSS tools you consistently use, you can add it in the comments below!

You've wrapped up your design, and it looks amazing, sleek, clean, and exactly how you envisioned it. You’re excited to see it come to life and watch users interact with your thoughtfully crafted interface and the features. But then, launch day comes, and you're left wondering: is this even the same design I worked on, or did the developers decide to remix it?

This article sheds light on common challenges that arise during development and what designers need to know about them. Understanding these aspects will help you create UI designs that are practical to implement, reducing the risk of disappointment.

As a Frontend Engineer with experience in both UI/UX design and development, I’ve encountered this issue firsthand and understand why it happens sometimes. In this article, I’ll explain the reasons behind these implementation gaps and share tips to help designers navigate this process more effectively.

Introduction

The interaction between design and development has changed a lot in modern web applications. Designers can’t just work on their own anymore; technical limitations and opportunities need to be considered from the very start. This does not mean limiting creativity, but about making smarter decisions that lead to better user experiences, while giving room for technical considerations.

When designers get a handle on things like component structure and how performance and security affects the design, they can be creative while still making sure it’s doable. It also helps designers and developers work together better, shifting the conversation from "Can we even do this?" to "What’s the best way to make this happen?"

The following highlghts are key technical factors UI designers should know about to create digital experiences that are not just creative and usable but also practical and functional.

Cross-Browser/Platform Compatibility & Rendering Differences

• Advanced CSS Styling Differences: Some advanced CSS features can behave differently depending on the browser that is being used. This applies to some CSS grid features and how it is handled or if it’s even recognized in some older browsers. This would affect a design trend like bento grid which relies heavily on CSS grids.

• Form Elements: Native form elements (like the checkboxes, radio buttons, dropdowns, checkboxes, sliders, etc) can look and work differently between browsers and operating systems. Custom styling helps to keep things consistent but sometimes, overriding default styling is harder or easier also based on the browser type.

• Fonts and Typography: Depending on the browser, fonts can look a bit different because of how some font properties are handled. Also custom fonts can look a bit off or act unpredictably across different devices and browsers. An example is when the font "Roboto" is used with a specified font-weight of 300 for headings, this is what happens on different browsers:

  • Chrome (Windows): The font renders as expected, light and clean due to Chrome's font rendering and anti-aliasing settings.

  • Firefox (Windows): The font appears slightly bolder compared to Chrome, as Firefox uses different anti-aliasing methods that emphasize clarity over weight precision.

  • Safari (Mac): The font looks sharper but slightly thinner because Safari tends to favor macOS’s native font smoothing.

• Color Display and Manangement: Colors might appear a bit different because there’s no universal color management across all browsers. Colors sometimes vary based on the device’s color profile. e.g an AMOLED display on Android might make the color appear more saturated than an LCD display on an older iPhone.

Performance Issues

• Animations: Complex animations or those with high frame rates might cause lag on older browsers or devices with lower power.

• Heavy Graphics: Large images, SVGs, or videos can slow down load times and might even cause the browser to crash. Always keep performance in mind.

Challenges with Responsiveness

• Breakpoints: Complex design makes development more complicated escpecially when considering that it has to fit across a lot of different breakpoints (like different tablets and small phones).

• Scaling Issues: Designs that are created to look perfect at a specific size (a fixed size inside Figma) might not adapt well to other screen sizes or resolutions. For example, elements could appear too small on a larger screen or too cramped on a smaller one if responsiveness isn’t considered during the design process.

• Images: In designing for responsiveness, one image might not be adequate for all screen sizes.

Scalability and Maintenance

• Over-customization: Highly unique or custom designs can be tough to maintain or update over time.

• Reusable Components: Designs that don’t follow consistent patterns might not fit well into the already existing reusable component strategy usually done by developers. This is why it's important to work with a component library or design system

State Management Complexity

• Dynamic States: Designs that include complex UI states like multi-step forms or dynamic filters can be challenging to implement without causing bugs or slowdowns.

• Error Handling: Things like error states, validation, and loading indicators sometimes get overlooked in designs, but they’re key to providing an overall smooth experience for users.

Backend and API Constraints

• Data Availability: If your design depends on specific data, like real-time updates or detailed analytics, it’s important to know whether the backend can support those needs.

• Performance Implications: Features like infinite scrolling or heavy data visualizations can put a lot of pressure on APIs and databases, which might affect performance.

• Security Implications: Features like infinite scrolling or heavy data visualizations can put a lot of pressure on APIs and databases, which might affect performance.

Content and Localization

• Text Lengths: When designing for multilingual sites, remember that translations can sometimes be longer than the original text. If this isn’t planned for, it can break the interface layout.

• Dynamic Content: Placeholder/fixed text (usually done in Figma) is often much shorter than real content. If you don’t design with actual content in mind (for both short and long text), it might end up in unexpected layout issues like text overflow.

Tips for Practical UI Designs

The following tips help in ensuring that your designs translate well into code while maintaining functionality and performance:

1. Design with modularity in mind: Think in reusable components. Instead of designing every button, card, or input from scratch, create a library of consistent, modular elements. This makes it easier for developers to replicate your designs across different pages or features. It also makes it easy for design to create interfaces. This is called a component library and a more detailed approach would be creating a design system which is made up of the design styles, component library, pattern library and interface elements.

2. Provide Layout Fallbacks: Not every browser or device will support complex layouts perfectly. Design alternative versions that adapt gracefully to technical constraints. An example is if a CSS Grid-based layout fails in implementation, ensure a flexbox or block-based fallback still delivers a readable and functional experience.

3. Provide Font Fallbacks: Custom fonts might not always load or render as expected. Provide or specify alternative system fonts to ensure your typography remains visually appealing and legible. On the frontend this is usually handled like by specifying in CSS like this - "Roboto", "Helvetica Neue", Arial, sans-serif.

4. Optimize Assets: Provide developers with optimized images, SVGs, and font files to improve performance and loading speed. Offer different image sizes (e.g., 1x, 2x, 3x) for responsive designs, and ensure SVGs are cleaned to remove unnecessary metadata (e.g an unwanted background or really small overlooked part).

5. Account for Edge Cases that go beyond the “ideal” scenario. Think about how your design will handle edge cases like extremely long user names or input values, empty states where no data is available, unexpected user behaviors, such as clicking buttons multiple times.

6. Design Loading and Error States: Include visuals for loading indicators, error messages, and empty states. These are sometimes overlooked but are critical for a seamless user experience.

7. Provide a Prototype: Interactive prototypes help developers understand your vision beyond static screens. Prototypes help to demonstrate how transitions, animations, and interactions should work. It also helps you as a designer to connect the flow step-by-step, which could help identify implementation issues and missing steps of the user flows.

8. Provide Animation Fallbacks: Animations can elevate user experience, but not all devices or browsers handle them well. Provide fallback designs for scenarios where animations can’t run smoothly.

9. Preview Designs Across Devices: Test your designs on various devices to identify potential issues early. This ensures your designs look and function as intended everywhere. This could be done by using the Figma's Preview and Figma Mirror after designing.

10. Design for Breakpoints Responsive design is essential. Define how your layout adapts across screen sizes by creating breakpoints for mobile, tablet, and desktop views. Test that the design works for the defined breakpoints. For example a breakpoint of

By following these practices, you’ll make your designs more practical for development, reduce back-and-forth, and create a better experience for both users and developers.

To developers, mention other limitations you would like designers to know about in the comments!

Credits

Cover image from https://uxdworld.com/20-famous-design-memes-to-make-you-laugh/

Setup/Prerequisites: React.js, TailwindCSS, Framer Motion

Key Concepts: Using infinite animation in Framer Motion

The Challenge

Day 2 is a simple loader which shows infinite animation by bouncing. This animation is quite simple but shows how Framer Motion handles infinite movements which is commonly used on loaders.

Key Animation Features

• Infinity movement

• Easing function for a more natural movement

Code Breakdown

1. Implementation Details

The ball is added first before going on to implement the infinite state and adding animations.

The animation happens in three main steps:

1. Wrap the ball image component with a motion.div element instead of directly applying motion to the image element to separate it’s styling.

2. Identify the states. There is only one state here - which is the infinite movement. The loaderVariants object is where this state is defined.

3. Specifying the transition type: The ininite movement and how it happens is defined in the transition property. Here, on the y-axis, I’m using the repeatType and repeat to create the infinite movement and the duration to define how fast this movement would be.

      y: {
            repeatType: "mirror",
            repeat: Infinity,
            duration: 0.5,
         }
   

2. Adding the Image

import { easeOut, motion } from "framer-motion";
import logoo from "../assets/image.png";
import grass from "../assets/grass.png";

const InfiniteLoader = () => {
  return (
    <div className="h-screen w-screen flex flex-col items-center justify-center afcad-flux">
      <motion.div>
        <img src={logoo} className="w-16 h-16" />
      </motion.div>
      <div>
        <img src={grass} className="h-24 " />
      </div>
    </div>
  );
};

export default InfiniteLoader;

3. Defining the Animations Using Code

In the loaderVariants object, the infinite state which has been previously identified is defined.

💡Remember to use gentle transitions

  const loaderVariants = {
    infiniteState: {
      y: [50, -50],
      transition: {
        y: {
          repeatType: "mirror",
          repeat: Infinity,
          duration: 0.7,
          easing: easeOut,
        },
      },
    },
  };

Live Demo

Resources Used

• Youtube tutorial by Framer Motion

Ideas for Enhancement ✨

What animation ideas do you suggest I add to this? I’m thinking of these:

• Adding sound effects

• Testing out other kinds of images, shapes and movement

Setup/Prerequisites: React.js, TailwindCSS, Framer Motion

Key Concepts: Using animate, whileHover, whileTap and variants in Framer Motion

The Challenge

Since today is day 1, I’m starting with a simple animation - a button that scales on hover and tap. This animation is quite simple but shows core Framer Motion concepts like variants and gesture animations.

Key Animation Features

• Smooth scale animation on hover

• Slight scale reduction on click/tap

• Subtle shadow animation

• Spring animation for natural movement

Some things you should take note of in these highlighted features are the italicized words and that’s because animations work best when they are used just in the right amount and in the right places - they should feel natural🤗

Code Breakdown

1. Implementation Details

The button is created first before going on to implement the different states and adding animations.

The animation happens in three main steps:

1. Wrap the button component with a motion.div element instead of directly applying motion to the button element to separate it’s styling.

2. Identify the states. Looking at the key animation features, there are 3 defined states I could get. The buttonVariants object is where the states are defined:

   • initial: The button's default state and styling

   • hover: The state where the button scales up and adds shadow on hover

   • tap: In this state, the button slightly scales down when clicked/tapped

3. Specifying the transition type: This defines how the button changes from one state to another. Here I’m using the spring transition which creates a bouncy, natural feel. The other properties related to the ‘spring’ transition are also set to properly add the mild transition effect.

   • stiffness: 400 makes the animation “snap“

     The value here usually ranges from 0 to 1000, with higher values making the animation more rigid, while lower values make it softer and slower.

   • damping: 10 This adds a slight bounce

     For damping the value ranges from 0 to 100, with higher values make the animation settle faster, while lower values create more bounce.

2. Coding the Animated Button

import { motion } from "framer-motion";

export default function AnimatedButton() {
  return (
    <div className="flex min-h-screen items-center justify-center bg-gray-100">
      <motion.div
        variants={buttonVariants}
        initial="initial"
        whileHover="hover"
        whileTap="tap"
      >
        <button className="bg-blue-500 px-6 py-2 text-white">
          Hover Me
        </button>
      </motion.div>
    </div>
  );
}

3. Defining the Animations Using Code

In the buttonVariants object, the different states which have been previously identified are defined using the styling specific to each state.

💡Remember to use subtle shadows

const buttonVariants = {
  initial: {
    scale: 1,
    boxShadow: "0px 0px 0px rgba(0,0,0,0.2)",
  },
  hover: {
    scale: 1.1,
    boxShadow: "0px 5px 15px rgba(0,0,0,0.2)",
    transition: {
      type: "spring",
      stiffness: 400,
      damping: 10
    }
  },
  tap: {
    scale: 0.95,
    boxShadow: "0px 2px 5px rgba(0,0,0,0.2)",
  }
};

Live Demo

Key Takeaways

• Spring animations feel more natural than linear ones like for interface elements.

• Small scale changes (like 0.95-1.1) are often more realistic.

• Combining scale with mild shadow creates a great three-dimensional effect.

Resources Used

• Framer Motion Gestures Documentation

• Spring Animation Documentation

Ideas for Enhancement ✨

What animation ideas do you suggest I add to this button? I’m thinking of these:

• Adding sound effects for interaction

• Creating different variants for different button states (loading, success and error)

SOLID is a set of object-oriented design principles. These principles establish practices for developing classes in object-oriented programming.

The SOLID principles aims to serve one purpose which is to create reusable, maintainable, flexible and easy-to-understand code in order to facilitate collaborative software development.

Despite being created for object-oriented programming, the principles of SOLID can be applied in React applications, although they may manifest slightly differently due to the nature of React being a library for building user interfaces rather than a strict object-oriented programming paradigm. In this article, you would see how each SOLID principle can be applied in the context of React.

S - Single Responsibility Principle (SRP):

Components should have a single responsibility. Separate concerns such as rendering, state management, and data fetching into different components or hooks to keep each component focused and maintainable.

For example, a Product Card component on an eCommerce website responsible for rendering product information (name, image, description) should only handle rendering the product and not perform unrelated tasks such as fetching data or component actions (e.g. on button click). Container components which sit above presentational components like ProductCard should handle data fetching, application logic, and pass down the data as props to presentational components.

From the image below, the code at the top, violates SRP because it has two concerns in the component code:

• Displaying product details

• Handling cart interactions (adding the product and managing errors).

The corrected code shows separated functionalities:

• The ProductCard now renders only product information (presentational information).

• The parent/container component handles interactions and other actions related to the children components.

O - Open/Closed Principle (OCP):

You should be able to extend the behavior of a component without needing to directly modify its source code. Use higher-order components (HOCs), composition or props to customize and extend the behavior of components rather than modifying their internals directly. This is closely related to the first principle.

Still using the ProductCard component, the first part of the image shows the component which violates the OCP principle, this makes it hard to reuse the ProductCard across the application because it now has a local handleAddCart function which cannot be customized.

L - Liskov Substitution Principle (LSP):

This principle emphasizes that objects (components in this case) of a superclass should be replaceable with objects of its subclasses without causing unexpected behavior. Create reusable components with well-defined props that can be easily substituted for one another in different parts of the application.

An example of this is a basic Button component that renders a button with a label and onClick handler. You then create a derived component PrimaryButton that inherits from Button and adds styles for a primary style button.

The first image which violates LSP, shows how the PrimaryButton directly modifies the props passed to the Button component - adding a style attribute. If another component expects a plain Button without styles and uses PrimaryButton as a replacement, it might break the UI due to unexpected styling.

I - Interface Segregation Principle (ISP):

The I in SOLID stands for the Interface Segregation Principle. This principle emphasizes that instead of having large, monolithic interfaces(props), it's better to break them down into smaller, more specific interfaces. This allows for greater flexibility and reduces the burden on classes (components) that implement these interfaces.

React heavily utilizes components, and interfaces(props) define the way components can interact with each other. ISP emphasizes that avoid passing large prop objects to components. Instead, break down props into smaller, more specific ones that components can use independently. The example below shows how the Interface Segregation Principle can be applied in React:

A ProductCard component that displays product information and allows users to add the product to their cart. Initially, you define a single interface, ProductProps, that includes all functionalities:

This interface serves the ProductCard component well. However, what if you want to reuse the product information display functionality (name, price, image) in another component, say a ProductSearchList component that displays a list of products? In this case, the ProductSearchList component doesn't need the addToCart functionality.

Following the Interface Segregation Principle, you can split the original ProductProps interface into two smaller ones:

Now, the ProductCard component can implement both ProductInfoProps and AddToCartProps, while the ProductSearchList component only needs to implement ProductInfoProps. This promotes better code reusability and reduces the dependencies between components.

Consider using ISP for components with multiple, distinct functionalities and potential for future growth.

D - Dependency Inversion Principle (DIP):

Avoid tight coupling between components by using dependency injection, context, or props drilling to pass dependencies down the component tree. Favor abstractions and interfaces over concrete implementations to decouple components and make them easier to test and maintain.

An example of how the DIP in React is this: Imagine you have a ProductCard component that fetches product data from a hardcoded API endpoint within the component itself. This creates tight coupling between the component and the specific data source.

Summary

While React may not be strictly object-oriented, the principles of SOLID can still guide you in writing cleaner, more maintainable React applications by encouraging modular, decoupled, and reusable component designs.

Though originally intended for object-oriented programming, the core concepts translate well to React's component-based structure.

In this article, I will be making a comparison between Gatsby and Create React App(CRA) to help you decide which is better for your project. These two are part of the most popular tools used to build React-based applications.

What is Gatsby.js?

Gatsby is a static site generator that is built using React as a framework. It uses React for the user interface and GraphQL for data querying & management. It is built with performance and scalability in mind, and it offers many features out of the box that can speed up development, such as image optimization and the use of plugins. With Gatsby, you can create websites that are both fast and friendly to search engines, which is important if you want people to find your website easily.

What is Create React App?

Create React App is a command-line tool that is used to set up a basic React application with only the minimal configuration required. It is a simple and lightweight solution for building React applications. With CRA, you can quickly get started building a React application without worrying about any extra configurations.

Things to consider

Performance

Performance is one of the biggest benefits of Gatsby. This is because Gatsby uses server-side rendering (SSR) to generate static HTML pages, which are served instantly to the user, resulting in faster page load times. In addition to this, Gatsby automatically optimizes images and other website assets, which further improves performance. CRA, on the contrary, does not use SSR and requires more configuration to optimize performance.

Functionality

Gatsby and Create React App significantly differ in terms of their core functionalities. Gatsby functions as a static site generator, whereas Create React App serves as a development tool. Gatsby generates static HTML and assets during the build process, while Create React App dynamically generates and serves your application at runtime. This fundamental difference influences the types of web applications each tool is best suited for.

Static web applications, like those built with Gatsby, focus on displaying pre-built content to visitors. These websites are constructed using HTML, CSS, and JavaScript, with the displayed content remaining fixed and unchanging. Examples of static web applications include blogs and portfolios, where the primary purpose is to present information to users.

Conversely, dynamic web applications, which are better built with Create React App, are built to deliver more personalized content to users based on how they interact with the site. These applications leverage server-side scripting, databases, and APIs to provide content that is tailored to each user's specific needs. E-commerce websites are a good example of dynamic web applications, as they dynamically update product listings, shopping carts, and user account information based on real-time interactions.

If your project primarily involves presenting pre-built content without much interactivity, Gatsby's static site generation capabilities make it an ideal choice. However, if you require a highly interactive and personalized web application that dynamically updates content based on user interactions, Create React App would be better.

Data Management

Another key difference between Gatsby and CRA is their approach to data management. Gatsby uses GraphQL, a query language for APIs, to fetch and manage data. This makes it easy to pull data from various conventional and even unconventional sources like Airtable and incorporate it into your website. Create React App, on the other hand, leaves data management up to you. You'll need to set up your own data fetching and management system, which can be time-consuming and complicated.

Development Approach

CRA provides just a basic React application structure without any additional features which offer a simpler, more familiar development experience for developers who prefer a "development from scratch" approach. This approach has its own benefits - you have complete control over the project structure and configuration. Meanwhile, Gatsby provides a more structured development experience, with many built-in features and a plugin system that can provide additional functionality to the site. It also offers many features out of the box that can speed up development, such as image optimization and pre-fetching. It also has a large collection of plugins and themes that can further enhance your web application's functionality.

How to determine which is better for your project

To determine the most suitable tool for building your application, consider asking yourself the following questions:

1. Do you want to build a static site or a dynamic web application?

   As explained earlier, Gatsby is designed for static web applications that don't require a lot of dynamic content. If you're building a simple blog or portfolio site, Gatsby is a great option while Create React App is better suited for dynamic web applications that require a lot of interactivity and real-time updates like E-commerce websites.

2. What is your development plan or approach?

   It is essential to consider your project's specific requirements and your development preferences. Create React App helps developers make customised configurations from scratch. However, it is worth noting that this customization process can require a deeper understanding of the underlying tools and build configurations. If your project needs a more streamlined development experience without extensive configuration, Gatsby might be a more suitable choice as it also provides a pre-configured setup and a comprehensive set of features, reducing the initial setup complexity and allowing you to focus more on the content and functionality of your website.

3. What is your data management approach?

   Gatsby uses GraphQL (a query language for APIs) to fetch and manage data. This makes it easy to pull data from different sources and incorporate it into your website. Meanwhile, you will need to set up data fetching & management in your Create React App, which can be complicated. Some more questions to ask yourself regarding this are:

   • Are you familiar with GraphQL and prefer its data querying capabilities?

   • Are you willing to set up your own data fetching and management system?

4. Is SEO important to your project?

   Gatsby is designed to be SEO-friendly out of the box. It automatically generates optimized HTML and meta tags, which can help your website rank higher in search engine results. Create React App, on the other hand, requires manual configuration to ensure good SEO practices.

5. What is your project deployment approach?

   Due to Gatsby's static site generation, it is easier to deploy your website to a static web hosting service, such as Netlify, Github Pages or Vercel. Create React App, on the other hand, needs a server to run, which means you will need to deploy it to a hosting service that supports server-side rendering, like Heroku.

Chakra UI is an open-source library of pre-built user interface components that simplifies web development for developers by allowing them to create functional websites quickly and easily without writing custom CSS or HTML code. These components, such as buttons, forms, and modals, are customizable and follow accessibility, usability, and responsive design best practices, making them user-friendly and accessible.

Chakra UI works well with popular front-end frameworks such as React and Next.js, but it can also be integrated with other tools and libraries. Although it provides several React-specific features, it is still built on top of CSS and HTML, allowing its CSS styles and components to be used with non-React web frameworks.

However, some of Chakra UI's features may not work optimally with non-React web frameworks. For example, its responsive design system relies on React's useState hook to detect screen size, so it may not work as expected without React. Additionally, Chakra UI's theming system relies on emotion, a CSS-in-JS library, so it may not work as expected.

Benefits of Chakra UI

• Theming system: With ChakraUI, you can easily customize the look and feel of your application. This means you can quickly and easily change the colour scheme, typography, and other design elements of your site to suit your style guide without having to rewrite any code.

• Accessibility: Chakra UI is designed with accessibility in mind, and it provides several accessibility features out of the box. For example, all components have proper aria attributes, the keyboard navigation is supported, and the colour contrast ratios comply with WCAG 2.1 guidelines. This ensures that websites built using Chakra UI are user-friendly and accessible to everyone.

• Use of best practices: Chakra UI is designed to follow best practices in accessibility, usability, and responsive design.

• Performance: Best practices integrated into this library ensure your application runs quickly and efficiently. Chakra UI uses a modern and lightweight design system based on styled-components. This allows the library to avoid heavy dependencies and ensures the CSS code is optimized for performance.

• Extensive features: Lazy loading and code splitting are part of the unique features ChakraUI gives developers access to. These features help to reduce the amount of code that needs to be loaded and executed by the browser, which can significantly improve page load times.

Global Styles in ChakraUI

Since ChakraUI is built with a theming system, default styling exists for all components and elements in the library. This can help ensure consistency in the appearance and behaviour of your UI components.

This tutorial will guide you through the process of modifying the default ChakraUI styling of any React application utilising this library by extending or overriding the global styles provided.

How to modify Global Styles in Chakra UI

The Project

To demonstrate how to modify ChakraUI, I'll be building a simple one-page website containing an Order summary component as shown in the image below.

Setting up ChakraUI

In React.js, there are two ways to install ChakraUI:

a. In a new folder:

• Simply run the following command in terminal

npx create-react-app <APPNAME> --template @chakra-ui

b. Or, in a newly installed create-react-app:

• Install react app

    npx create-react-app <APPNAME>
    cd <APPNAME>
  

• Inside the project directory, run the following in the terminal

    npm i @chakra-ui/react @emotion/react @emotion/styled framer-motion
  

• Setup Provider: You need to set up the ChakraProvider at the root of your application. This should be in your index.js file

    //index.js file
    import React from "react";
    import ReactDOM from "react-dom/client";
    import "./index.css";
  
    // 1. import `ChakraProvider` component
    import { ChakraProvider } from "@chakra-ui/react";
    import App from "./App";
  
    // 2. Wrap ChakraProvider at the root of your app
    const root = ReactDOM.createRoot(document.getElementById("root"));
    root.render(
      <React.StrictMode>
        <ChakraProvider>
          <App />
        </ChakraProvider>
      </React.StrictMode>
    );
  

Using ChakraUI's default styling

• I setup the project and developed it using CharaUI's default styling and this is what the frontend code looks like https://github.com/maryojo/order-summary-chakra-tutorial/blob/d0a00421de81a43760e93c0ba547d033c1adf658/src/App.js

• Result: https://644b7458337d8467791f868c--lambent-llama-1b74cc.netlify.app/

Modifying global styles in ChakraUI

Theming in Chakra UI follows the Styled System Theme Specification approach, where a theme object defines the application’s colour palette, font, breakpoints, spacing, and more.

To modify the existing codebase to suit the application's theme, we'll be overriding the default font family and colours of some components

• Create a file named Theme.js in the src folder

• Import extendTheme module in Theme.js file

    //Theme.js file
    //1. Import extendTheme
    import { extendTheme } from "@chakra-ui/react";
  

• Create a theme object which would contain the formatted styles as shown below:

    //Theme.js file
    //1. Import extendTheme
    import { extendTheme } from "@chakra-ui/react";
  
    //2. Theme object containing custom styling
    const themes = {
      styles: {
        global: {
          'html, body': {
            backgroundColor: 'hsl(225, 100%, 94%)',
            fontFamily: `'Red Hat Display', sans-serif`,
          },
          a: {
            color: 'hsl(245, 75%, 52%)',
          },
          h1: {
            color: 'hsl(245, 75%, 52%)',
            fontSize: '64px',
             lineHeight: '80px',
          },
        },
      },
    }
  

• Export theme

    //Theme.js file
    //1. Import extendTheme
    import { extendTheme } from "@chakra-ui/react";
  
    //2. Theme object containing custom styling
    const themes = {
      styles: {
        global: {
          'html, body': {
            backgroundColor: 'hsl(225, 100%, 94%)',
            fontFamily: `'Red Hat Display', sans-serif`,
          },
          a: {
            color: 'hsl(245, 75%, 52%)',
          },
          h1: {
            color: 'hsl(245, 75%, 52%)',
            fontSize: '64px',
             lineHeight: '80px',
          },
        },
      },
    }
    //3. Export theme
    const theme = extendTheme(themes);
    export default theme;
  

• Call the theme as a prop in ChakraProvider in the index.js file

     //index.js file
     import React from "react";
     import ReactDOM from "react-dom/client";
     import "./index.css";
  

import theme from Theme;

// 1. import ChakraProvider component import { ChakraProvider } from "@chakra-ui/react"; import App from "./App";

// 2. Wrap ChakraProvider at the root of your app const root = ReactDOM.createRoot(document.getElementById("root")); root.render( <React.StrictMode> </React.StrictMode> ); ```

Final result

Any more custom styling could be added to the Theme.js file in the format shown. ChakraUI's styling could also be used to create custom styles for components.

Code: https://github.com/maryojo/order-summary-chakra-tutorial

Live site: https://lambent-llama-1b74cc.netlify.app/

Further steps

Read more about ChakraUI's global styles from the documentation

Accessibility matters even on the web!

The goal of web accessibility is to ensure that everyone has equal access to information, services, and a good user experience irrespective of their abilities or disabilities. Web accessibility refers to measures taken to ensure that all individuals inclusive of those with disabilities can access and use websites and digital content with ease. To achieve this, websites should be created in a way that is perceivable, operable, understandable, and robust, providing access for everyone. This approach fosters inclusivity and equal opportunities for all users.

Semantics

The word 'semantic' means the study of the meaning of language. It helps to ensure that communication is clear and accurate by providing context and meaning to language. In the same vein, semantic HTML is the use of HTML markup in a way that accurately conveys the meaning and purpose of the content on a web page. Semantic HTML is a backbone for web accessibility. It is how accessibility is incorporated into websites.

Why do we need Semantic web content?

• It adds meaning to your HTML content, which lets web browsers, search engines, screen readers, RSS readers, and ultimately users understand it and easily navigate and interact.

• It improves SEO. Semantic HTML makes it easier for search engines to understand the flow and content of a page. This makes your website easier to discover.

• Code written in semantic HTML makes it easier for other developers to maintain and update.

Using Semantic HTML

There are 2 major ways to give HTML content more meaning.

1. The proper use of HTML tags

   The proper use of HTML tags is crucial for providing structure and meaning to web content, making it easily understandable to both humans and machines. It is essential to use HTML tags in a semantically correct manner, where they accurately reflect the content and purpose of the element they are applied to.

   For instance, it is semantically correct to use the <h1> tag to mark up the main heading of a web page. In contrast, using a <div> tag with a large font size is not semantically correct and should be avoided.

   By using HTML tags correctly, web content becomes more accessible to users with disabilities. An example is using the <img> tag to include alternative text descriptions for images helps users with visual impairments understand the content of the image. Similarly, using the <label> tag with form elements such as text inputs and checkboxes makes it easier for screen reader users to understand the purpose of the form element and how to interact with it.

   In addition to the <h1>, <img>, and <label> tags, several other semantic HTML tags are commonly used to provide structure and meaning to web content.

   The <nav> tag is used to mark up the navigation section of a web page, while the <article> tag is used to define a self-contained piece of content, such as a blog post or news article. The <header> and <footer> tags are used to define the header and footer sections of a web page, respectively. The <main> tag is used to define the main content of a web page, while the <aside> tag is used to define content that is tangentially related to the main content, such as a sidebar or a call-to-action section.

   Using these tags correctly helps to make web content more accessible and understandable for all users, including those with disabilities. A comprehensive list of semantic HTML tags and their uses can be found on the MDN website, which provides a reference for web developers to follow when creating accessible and semantically correct web content.

2. ARIA attributes

   ARIA stands for Accessible Rich Internet Applications. These attributes are a set of HTML attributes used to define accessibility features for web content. Assistive technologies such as screen readers use the additional information provided by ARIA attributes. ARIA attributes can be used along with semantic HTML tags or whenever semantic HTML cannot be used. ARIA attributes can be used to provide additional information about the elements on a web page, specifically in four ways:

3. • Roles: ARIA roles define the type of element and its purpose. For example, an element can have a role="button" to indicate that it is a clickable button.

     • States: ARIA states describe the current state of an element. These states can be combined with ARIA roles and properties to provide a more complete picture of the accessibility and functionality of elements on a web page. An example is an element with aria-expanded="true" to indicate that it is currently expanded.

     • Properties: ARIA properties provide additional information about an element. For example, an element can have aria-level="3" to indicate that it is a heading at level 3.

     • Labels: ARIA labels provide a way to associate a visible label with an element that is not visible or has an ambiguous label. For example, an icon that represents a trash bin can have aria-label="Delete" to indicate its function.

This webpage provides a list of all ARIA roles, properties, states and labels, which have been defined by W3C (the organization that develops web standards).

Example showing the use of ARIA attributes

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>About Us</title>
</head>
<body>

  <div>
    <div role="banner">
      <h1>About Us</h1>
      <nav role="navigation">
        <ul role="menu">
          <li role="menuitem"><a href="/" role="link">Home</a></li>
          <li role="menuitem" aria-current="page"><a href="/about" role="link">About</a></li>
          <li role="menuitem"><a href="/contact" role="link">Contact Us</a></li>
        </ul>
      </nav>
    </div>
  </div>

  <main>
    <div>
      <div role="region">
        <h2>Our Mission</h2>
        <p role="paragraph">Lorem ipsum dolor sit amet, consectetur              adipiscing elit. Aliquam auctor nisl eget augue laoreet vestibulum. Sed sit amet orci bibendum, tincidunt ex ac, euismod velit. </p>
      </div>
    </div>
  </main>

</body>
</html>

Testing web semantics using accessibility tools and resources

There are many tools and resources which range from simple web browser extensions to accessibility testing suites that help developers create semantic and accessible web content for all users.

Tools

1. HTML validators:

   HTML validators check the syntax and validity of HTML code and report any errors or warnings. They can help identify and fix issues that may affect the accessibility of web content, such as missing or incorrect attributes, nested elements, or deprecated elements.

   • Online HTML validation tools: An example is The W3C Markup Validation Service, this validator checks the markup validity of web documents in HTML, XHTML, etc. It supports HTML5, SVG 1.1, etc. It can validate by URI, file upload, or direct input.

   • HTML Validation IDE settings: Some Integrated Development Environments (IDEs), such as RJTextEd, have built-in HTML validators that can be used to validate HTML code.

   • HTML validation extensions: In cases whereby the IDE does not have a built-in HTML validator, extensions like HTMLHint which is available for VSCode could be installed.

2. Screen reader emulators:

   By using a screen reader emulator, developers can test their web content and ensure that it is properly structured and labelled with the appropriate HTML tags. A screen reader emulator can help developers ensure that their web content is compatible with popular screen readers like JAWS, ChromeVox, NVDA, and VoiceOver. Some examples are:

   • WebAnywhere: This is a web-based screen reader that works from any browser without installation. It can read aloud web pages and provide keyboard navigation. It is free and open source.

   • Silktide Disability Toolbar: This is a Chrome extension that allows you to experience your website with a range of simulated disabilities, including blindness and partial sightedness. It also has a screen reader simulator that can read aloud text and navigate with keyboard or mouse. It is free to use.

3. Accessibility testing tools:

   • The WAVE Web Accessibility Evaluation Tool, which is a free web browser extension can help identify accessibility issues on a web page.

   • Lighthouse, which can be used in Chrome DevTools, from the command line, or as a Node module. It generates a report on how well the web page did in terms of performance, accessibility, and more and then provides suggestions for improvement.

Resources

In addition to tools, there are also many online resources available.

• The MDN doc mentioned above.

• The Web Content Accessibility Guidelines (WCAG) by the World Wide Web Consortium (W3C).

• The ARIA Authoring Practices Guide, which guides on how to use ARIA attributes to improve the accessibility of web content.

• The HTML Living Standard

Conclusion

Web accessibility is a critical aspect of development that ensures everyone can access and use digital content. Semantic HTML is one of the fundamental building blocks of web accessibility, as it provides structure and meaning to web content. Using HTML tags in a semantically correct way is important because it helps both humans and machines understand the purpose and function of different elements on a web page. In addition to using semantic HTML tags, developers can utilize ARIA attributes to further enhance web accessibility. These attributes can define roles, states, properties, and labels for elements on a web page, making it easier for users with disabilities to interact with web content.

To create more accessible web content, developers and designers can use a variety of tools and resources available online. By prioritizing web accessibility in their development or design practices, they can help ensure that everyone has equal access to digital content.

In this tutorial, I will be creating a simple image recognition app in order to explain how to integrate Azure Computer Vision into client-side applications. You could also adapt the steps here to build similar applications using other services in Azure Computer Vision.

Prerequisites: Knowledge of React.js, An Azure account (you can get it free here), Github, Hosting service e.g. Netlify

Links: Code Live Site

Steps:

Step 1. Create and setup React App, then install dependencies

• Start by creating the react project:

npx create-react-app <APP_NAME>
cd <APP_NAME>

• Delete unused default files in boilerplate e.g. App.test.js, App.css

• Install Azure Computer Vision & MS Rest Azure npm package

npm i @azure/ms-rest-azure-js  @azure/cognitiveservices-computervision

Step 2. Setup resources on Azure

• Log in to the Azure Portal

• Create a new Computer Vision resource in Azure

• Fill out the form with the required information

  

• Click on 'Review+Create'

• The screen below shows after the resource has been deployed

• Click on manage keys to copy the API key and endpoint

Step 3. Add Azure details to the local React App

• In the react app root folder, create a new file called .env to store Azure access information in your local environment i.e. <APP_NAME>/.env

• Open the .gitignore file and add .env to the list

• Open the .env file and save the API key and endpoint here

// <APP_NAME>/.env
REACT_APP_apiKey = <YOUR_API_KEY>
REACT_APP_endPoint = <YOUR_ENDPOINT>

• In the terminal, run the command npm start to view the app in your browser

Step 4. Creating the Azure Vision Component

• Create a new folder called components in ./src

• Create a new file called AzureVisionService.js

• In the new file, copy and paste the code below, it contains information for requesting from the API. The documentation to better understand this part of the code is here. The describeImage method used is one of the available Azure Vision API methods. It describes an image with complete English sentences. Another similar method is the analyzeImage method which extracts a rich set of visual features based on the image content.

// ./scr/components/AzureVisionService

// Importing the Azure SDK client libraries
import { ComputerVisionClient } from '@azure/cognitiveservices-computervision';
import { ApiKeyCredentials } from '@azure/ms-rest-js';

// Authentication requirements
const key = process.env.REACT_APP_apiKey;
const endpoint = process.env.REACT_APP_endPoint;

// Cognitive service features
const options = {
    maxCandidates: 5,
    language: "en"
  };

// Describe Image from URL
export const computerVision = async (url) => {

    // authenticate to Azure service
    const computerVisionClient = new ComputerVisionClient(
        new ApiKeyCredentials({ inHeader: { 'Ocp-Apim-Subscription-Key': key } }), endpoint);

    // describe image using the describeImage method
    const analysis = await computerVisionClient.describeImage(url, options)
    .then((result) => {
        console.log("The result is:");
        console.log(result);
        return { "URL": url, ...result};
      })
      .catch((err) => {
        console.log("An error occurred:");
        console.error(err);
        alert(err + "Upload an image with a smaller size");
      });

    // all information about image
    console.log("This is:" +analysis);
    if(analysis === undefined){
        return "There is something wrong with the image"
    }
    return { "URL": url, ...analysis};
}

Step 5: Connect the AzureVision Component with the rest of the app.

• Import the required functions from the AzureVIsion Component into App.js

// ./src/App.js
import React, { useState } from 'react';
import { computerVision } from './components/AzureVisionService';

function App() {
  const [file, setFile] = useState(null);
  const [analysis, setAnalysis] = useState(null);
  const [processing, setProcessing] = useState(false);

  const handleChange = (e) => {
    setFile(e.target.value)
  }
  const onFileUrlEntered = () => {

    // hold UI
    setProcessing(true);
    setAnalysis(null);

    computerVision(file).then((item) => {

      // reset state/form
      setAnalysis(item);
      setFile("");
      setProcessing(false);
    });

  };

  // Display JSON data in readable format
  const PrettyPrintJson = (data) => {
    return (<div><pre>{JSON.stringify(data, null, 2)}</pre></div>);
  }

  const DisplayResults = () => {
    return (
      <div>
        <h2>Computer Vision Analysis</h2>
        <div><img src={analysis.URL} height="200" border="1" alt={(analysis.description && analysis.description.captions && analysis.description.captions[0].text ? analysis.description.captions[0].text : "can't find caption")} /></div>
        {PrettyPrintJson(analysis)}
      </div>
    )
  };

  //Describe image
  const Describe = () => {
    return (
    <div>
      <h1>Describe image</h1>
      {!processing &&
        <div>
          <div>
            <label>URL</label>
            <input type="text" placeholder="Enter an image URL" size="50" onChange={handleChange}></input>
          <button onClick={onFileUrlEntered}>Describe</button>
          </div>
        </div>
      }
      {processing && <div>Processing...</div>}
      <hr />
      {analysis && DisplayResults()}
      </div>
    )
  }

  return (
    <div>
      <Describe/>
    </div>

  );
}

export default App;

Step 6: Hosting your web app

You could use any preferred hosting service like Azure Static Web Apps, Netlify, Vercel, Firebase or Heroku. For this tutorial, I'll make use of Netlify. One important thing to note is that whichever hosting platform you use, remember to add the REACT_APP_apiKey and the REACT_APP_endPoint to the host environment variables.

• The first step here is to push the local react app to Github. Create a new empty repository in Github, you should get the screen shown below

• In your local react app folder, open a new terminal. Then run the following commands

// In bash terminal
git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/<USERNAME>/<REPO_NAME>.git
git push -u origin main

• Your code is now pushed to Github. Next, open your hosting website and import the existing project from Github.

• In the build and deploy setup interface, click on 'Advanced Settings' then 'Add New Variable' to store the secret keys

• Then deploy your site

Your site is deployed!!

References:

1. Microsoft Docs Image Analysis Tutorial

2. Azure Computer Vision npm doc

3. Azure Computer Vision API doc