In organisations today, data has never been more available. Dashboards and performance decks exist for almost every function — sales, product, marketing, operations — and the tools to build them have never been more accessible. And yet, in weekly standups and quarterly reviews, the same thing happens constantly: someone shares the numbers, the room nods, and the meeting ends without a decision or clear direction.

When that happens, the data usually takes the blame. The numbers weren’t granular enough, the dataset wasn’t complete, we need more information before we can act. But the data is almost never the problem. The reality is that nobody designed it to deliver insights. The chart was built from what was available, not from the question that needed answering. The audience was assumed rather than understood, and what should actually change as a result of seeing this data — that question — was never asked at all.

Data visualisation and UX are solving the same underlying problem: both are trying to move the right information to the right person in a way that changes something. The vocabulary is different, but the underlying challenge is identical, and the moment you start treating them as complementary disciplines is the moment dashboards stop being a passive collection of charts and start doing something functional.

For designers who work with data, analysts who present to non-technical audiences, and marketers who need their numbers to do more than sit in a slide, this read is for you.

The Chart Was Never The Whole Story

In 1973, the statistician Francis Anscombe (PDF) published a paper that made a quiet but clarifying point. He constructed four datasets that are statistically identical: same mean, same variance, same correlation coefficient, and same regression line. Run the numbers on any of them, and they are identical. Plot them, and they could not be more different.

Anscombe’s lesson to statisticians was about diagnosis: visualisation reveals the operational truth that raw numbers conceal.

But visualisation isn’t just diagnostic; it is also communicative. The form you choose is where understanding either emerges or gets lost in the noise. Does your audience walk away with numbers, or with a story they’ll quote and talk about?

One of the most striking examples is Visual Capitalist’s History of Pandemics. Instead of burying the reader in a massive data table of casualty counts, it maps the death toll of major historical pandemics using a proportional bubble layout on a single timeline.

Before your brain reads a single number, your visual system grasps the sheer scale of the Black Death relative to everything else on the page. The right visualisation does not just plot the data but makes the story impossible to miss.

Edward Tufte codified a foundational principle for the craft with his data-ink ratio: every mark on a chart should serve the data, not decorate it. It remains a widely used framework in data visualisation, anchored in the assumption that clarity and visual hygiene are the goal.

For a chart in isolation, that holds. But a chart is never read in isolation: it’s read by a person, in a specific context, under specific pressure. Strip a chart down to its cleanest form, and you might be removing the exact layer of context a decision-maker needs. Simplicity isn’t the goal in itself; appropriate complexity is.

Data is a message, and the right amount of signal depends entirely on who’s receiving it.

Which leads to the core principle of data UX: roughly 80% of the work that determines whether a dashboard succeeds happens before you ever draw a chart.

That dependency is the thread the rest of this piece pulls on.

The 80% That Happens Before The Chart

The high-leverage 80% almost never happens on screen. It happens upstream: before a tool is opened, before a dataset is pulled, before a single design choice is made. It comes down to three questions, and once they become habitual, they change what you notice, what you ask, and what you push back on at the outset of every project.

1. Context: What are we trying to show with this data?
   This is where you define what the visualisations actually need to serve before you touch any raw data. Writing down the precise operational questions, specifically enough to determine what gets pulled and what gets filtered, is what produces a dashboard that helps with decision-making.
2. Audience: Who is this for, and how do they think?
   This is the empathy step. Knowing who’s in the room, what they’re accountable for, and how they engage with data determines how much complexity the visualisation can carry, and how it should be presented.
3. Insight: What should change once this data lands?
   A decision, a new direction, a shift in understanding. If the intended strategic outcome isn’t clear during the design phase, it will remain invisible once the dashboard goes live.

Context: What Are We Trying To Show With This Data?

Most data-heavy projects start backward: teams pull whatever metrics their internal analytics tools already track and build visualisations around them, while the question the data was supposed to answer either gets assumed or never gets asked. This happens simply because we anchor on the data in front of us as the boundary of what’s possible.

Defining a goal first sounds obvious, but in practice, it rarely happens with the necessary clarity. “Show me how the product is performing” is not a goal; “Identify which features drive retention among users who signed up in Q1” is, as it includes three things the first doesn’t: a metric, a population, and an implied action. That specificity is what converts an open-ended exploration into a constrained, answerable design problem. Which one you start from determines everything that follows: what you include, what comparisons matter, and what you leave out entirely.

Starting with available data produces a dashboard that answers no particular question, because it was never built for one — every number is present, none of them pointed anywhere. Starting with the operational question does the reverse: every element on the screen earns its place, because each one is there to help answer it.

For example, consider a UX team trying to fix a leaky checkout flow for an e-commerce website. A data-first approach pulls everything available, from clicks to scroll depth and device types, yielding a massive dashboard that leaves everyone asking, “Okay, but what do we actually change?” A context-first approach starts with a constraint: “At which step of the checkout do users drop off?” By filtering out 90% of the noise, the team builds a simple funnel chart, instantly spots a bottleneck on the payment screen, and knows exactly what to redesign.

Audience: Who Is This For, And How Do They Think?

Designing for an audience comes down to two things: accountability and familiarity.

Familiarity is about data literacy. Do they read charts instinctively, or does a complex visualisation create friction? Handing a dense, multi-layered dashboard to a Head of Sales and a senior analyst is like giving the same map to someone who navigates by landmarks and someone who reads grid coordinates. The data is accurate, but it is only functional for one of them.

Accountability dictates how that complexity must be presented. A chart showing a 12% decline carries vastly different weight for the executive responsible for that number versus the analyst simply reporting it. Understanding your audience means grasping this relationship; data is never processed neutrally when your performance is on the line.

Together, familiarity and accountability decide one practical thing: how much you can put in front of someone.

In data visualisation, simplicity is not a fixed virtue — the right level of it is contingent on who is reading, and what they need to do.

An analyst relies on a high-density environment to conduct diagnostic discovery. By isolating individual behaviour nodes and mapping out raw user flows, they interrogate the data at its atomic level to uncover the hidden insights and underperforming spend that will shape future campaigns.

An executive, by contrast, requires a highly synthesised translation of that data to immediately identify what is driving commercial growth. Tailoring a dashboard to your audience means adjusting the density dial, delivering maximum signal with appropriate complexity for the specific brain in the room.

Insight: What Should Change Once This Data Lands?

Most data projects operate on the comfortable assumption that if a chart is accurate and clear, the insight will take care of itself. In reality, information and insight are entirely different states. Information is what the data shows, whereas insight is the specific decision, shift in understanding, or course correction someone makes as a result of seeing it. If the intended business change isn’t defined before the design begins, a dashboard will default to passive reporting rather than driving action.

Marketing and engineering teams experience the danger of this gap whenever a core business metric suddenly plummets.

A dashboard built for information simply sounds the alarm, showing a chart that tracks a sharp 15% drop in booking rates. Because the data lacks depth, leadership defaults to panic: they immediately call the UX design team, assuming the app is broken or the checkout flow is flawed. Because the data doesn’t pinpoint the core of the problem, it triggers a costly, misplaced fire drill.

A dashboard built for insight isolates the variables required to make an informed decision. Instead of a single, flat booking metric, the visualisation maps the drop against traffic sources and campaign launches — instantly revealing that while app performance and core user conversion are perfectly stable, the sitewide rate was artificially diluted by a massive influx of low-intent click traffic from a newly scaled campaign. The team doesn’t waste time redesigning a functioning app; they get the exact insight needed to pause the underperforming marketing campaign and adjust their acquisition strategy.

Every visualisation implies a next step, even if that step is “nothing needs to change right now.” The question is whether the design makes that implication clear enough for the viewer to recognise it.

From Questions To Dashboard: A Project Walk-through

My aha moment in data visualisation happened during a project for a client-facing B2B SaaS platform focused on enterprise talent management and competency tracking in Pegasystems skills. The platform captured a massive footprint of daily telemetry, and the brief arrived open-ended: “We have an immense archive of user activity, now we need to present it to enterprise teams.”

We could very easily have charted everything that was captured, but we wouldn’t be doing end users any favours if they just ended up looking at a data graveyard. My responsibility immediately moved beyond pure interface craftsmanship; it became about architecting a highly practical tool for real people who would open this dashboard routinely and need it to tell them an honest, immediate story about their workflows.

Here is how the project actually went.

Context

The client believed this massive pool of data could help their users perform better, and wanted an interface that finally enabled that growth. Translating that broad ambition into tangible visualisations required defining the practical mechanics of performance. What variables indicate advancement vs passive usage? What does “perform better” actually mean? How do you measure it?

An obvious candidate was time spent by product. Every platform tracks it. It is easy to show, and it feels meaningful. But time spent is a proxy; it tells you someone was there, not whether they got anything out of it.

The more meaningful signals were competency scores by area, certification completion rates, and historical performance trajectories. Integrating time-spent data alongside these performance metrics added a useful layer of interpretation, helping us surface which modules users were underutilising and whether that directly correlated with lagging scores. Time spent became a supporting signal in the larger story.

The second question was about the appropriate level of granularity. An identical metric carries completely different weight depending on who is looking at it. An individual contributor tracking their own completion rate needs to know if they are pacing correctly, whereas a manager reviewing a team aggregate needs to know precisely who requires immediate support. This distinction shaped every subsequent data-exposure and filtering decision. Defining that structural story early determined exactly what to show, and to whom.

Audience

The most straightforward approach to this design would have been predictable: use the same charts, but offer an individual view and an aggregated team view. Far too many dashboards rely on this shortcut, subtly tweaking the scale of identical data visualisations and labelling it “personalisation.”

An authentic analysis of the audience reveals a much deeper rift. Frontline team leads and individual contributors required distinct narrative structures and design principles.

Having used e-learning platforms myself, I remember the frustration of opening a tool without a clear sense of my current standing, core strengths, or slipping metrics. That personal experience directly guided the individual contributor workspace; it needed to act as a highly tailored, self-directed mirror that was granular, honest, and personal.

Conversely, the manager’s interface had to bypass individual milestones initially to provide a macro pulse check on team vulnerabilities. It was designed around a different operational reality: how is the group progressing, and where are the consistent gaps? The view prioritised the aggregate picture first, while retaining an intuitive path to drill down into tactical day-to-day coordination when needed.

Insight

Our insight strategy was locked in during the early conceptual phase, long before wireframing a single chart. We intentionally abandoned the idea of building a dense, passive data log and focused on pacing the narrative arc.

For individual contributors, the core value was self-direction, ensuring they could glance at the interface on a Monday morning and immediately derive a clear priority list for the week ahead.

For managers, the goal was to fundamentally shift the timing of operational conversations, providing them with the necessary baseline to intervene before a skill gap evolved into a critical project failure. The visualisations needed to surface the exact moments when a human check-in would be useful, shifting their workflow from reactive post-mortems to proactive guidance.

The comparison tool was the highlight nobody had asked for. A manager dashboard and an individual dashboard are easy to anticipate. What is harder to land is: what if a manager wants to compare two specific team members against the same metrics, side by side? That view came from a design assumption, and it turned out to be the feature that resonated most.

The decisions that mattered most in this project weren’t in the initial brief — capturing data they hadn’t thought to request, and structuring it to answer questions they had not previously known how to articulate, which is the core differentiator of a user-centric data strategy.

Designing The Mental Model Early

The choice of visualisation layout must follow the geometric nature of the data itself. For this project, the core design problem was enabling an individual user to answer a specific question at a single glance: across eight distinct competency areas, where are my relative strengths and gaps?

To solve this, we mapped the data using a radar chart. By organising multiple variables across axes radiating from a central point using polar coordinates, the interface connects the data points to form a single, unified shape. An even, balanced polygon instantly signals well-rounded proficiency, while a sharply skewed shape draws the eye immediately to an outlier area.

While a traditional linear bar chart would have forced the viewer to scan eight individual bars and mentally calculate the variance, a concentric, radial layout segments the data layers to make progress tracking and skill gaps immediately readable. When all dimensions share an identical scale and scoring method, the radar chart is not an unconventional aesthetic choice — it is the most functional tool for multi-dimensional analysis.

The colour system was the other decision made early, and I mean early. During the branding exercise, each of the three products was assigned a colour. That colour did not stay in the brand guidelines. It was built into the data model from the beginning, running consistently across every chart, every filter, every breakdown. By the time a user landed on the dashboard for the first time, the mental model was already in place. They had not been taught the language. They already knew it.

What Changed

The shift from passive information to active insight showed up first in how the dashboard was actually used. Following the deployment of the personalised dashboards and side-by-side team comparison tools, weekly active engagement on the platform’s analytics features rose noticeably, per internally reported figures. Managers were no longer opening the tool once a month to pull static reports. They were using it every Monday morning to actively plan their week.

Revenue and user growth also moved in the right direction over the following two quarters, though — as with most single-project outcomes — it’s hard to isolate the dashboard’s exact contribution from everything else that changed at the same time. The client reported churn across the platform falling to one of its lowest points on record. The clearest evidence of impact came from qualitative feedback. Managers reported that instead of using data to dissect a ‘bad’ month after the fact, the visualisations allowed them to instantly spot slipping performance and schedule a quick supportive catch-up before it turned into a real gap.

Closing

Data design reaches its full potential when visual presentation is treated as an upstream architectural choice rather than a downstream formatting step. Bringing structured UX thinking to data turns visualisations into active decision-making engines, ensuring every chart, report, and metric directly serves a human purpose:

• Upstream framing: Grounding every visual choice in a specific operational question rather than defaulting to available metrics.
• Calibrated density: Tuning the level of complexity directly to the literacy and accountability of the specific reader.
• Decision-driven insight: Structuring data to reveal strategic outcomes rather than isolated stats, turning visual signals into immediate operational momentum.

The next time you are tasked with creating a data visualisation — whether it is an enterprise dashboard, an executive report, or a public-facing infographic — step away from the design canvas and BI tools. Focus your initial effort on the human decisions behind the screen. Only then will your data stop being a passive log of the past and start driving the direction of the future.

(yk)

The post Rethinking Data Visualisation: A UX Approach To Dashboards That Actually Drives Decisions appeared first on The NOKIA Blog.

Twenty years ago today, Jeff Barr wrote a blog post that launched the Amazon EC2 Beta. That single post introduced resizable Linux virtual servers in the cloud, billed by the hour, with one instance type (m1.small) in one Region (US East). It was minimal yet useful, and it changed how the world thinks about computing infrastructure.

In 2021, Jeff covered the fifteen years of EC2 with the backstory and memorable EC2 launches. Over the last five years, AWS has continued to push the boundaries of what cloud computing can deliver, building custom silicon for general-purpose and AI workloads and expanding EC2 into new form factors and deployment models that our customers in 2006 could not have imagined.

The 20 years in brief
In his 15th anniversary post, Jeff chose important milestones of EC2 that established the foundational building blocks that customers still rely on today. Amazon Elastic Block Store (2008) provided persistent block storage. Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch (2009) made applications scalable and highly available. Amazon Virtual Private Cloud (2009) gave customers logically isolated networks. AWS Nitro System (2017) enabled faster innovation and enhanced security. AWS Graviton processors (2018) were designed for cost-sensitive scale-out workloads.

Over 20 years, EC2 grew from one to over 1,200 instance types to meet customer needs across general-purpose, compute-, memory-, and storage-optimized, accelerated computing, and high-performance computing families. These instances expanded from one AWS Region to 39 Regions globally. AWS also extended EC2 beyond the Region boundary with AWS Outposts (2018) running EC2 instances locally, AWS Local Zones (2019) place globally, and AWS Wavelength (2019) inside global 5G telecommunications carrier networks.

While I hate to play favorites, I want to choose some of my favorite EC2 launches of the past five years:

• AWS Inferentia for ML inference at scale (2019): We introduced purpose-built ML inference instances (inf1) with AWS Inferentia chips. Amazon EC2 Inf2 instances became generally available in April 2023 for large-scale generative AI inference workloads. Together with the Inferentia family, AWS Trainium instances now give customers a full stack of AWS-designed silicon optimized for every phase of the AI lifecycle both inference and training.
• EC2 Mac instances (2020): The first Mac instances (mac1) were built on Apple Mac mini with Intel Core i7 (Coffee Lake) on the AWS Nitro System. Mac M1 (mac2) instances launched in July 2022 as the first Arm-based macOS instances on EC2. M2 Pro Mac instances followed in 2023, M4 and M4 Pro Mac instances in 2025, M3 Ultra Mac instances and M4 Max Mac instances in 2026, giving Apple developers a complete range of cloud-based build and test environments for macOS, iOS, iPadOS, tvOS, watchOS, and visionOS apps.
• AWS Trainium for full-stack AI workloads at scale (2021): In November 2021, we previewed Trn1 instances with AWS Trainium accelerators optimized for high-performance deep learning training. In December 2024, Trn2 instances powered by AWS Trainium2 launched, with Trn2 UltraServers linking 64 Trainium2 accelerators via NeuronLink for training trillion-parameter foundation models. At AWS re:Invent 2025, Trn3 UltraServers powered by AWS Trainium3 deliver the best token economics for next-generation agentic, reasoning, and video generation applications. A single Trn3 UltraServer interconnects up to 144 Trainium3 chips to train and serve the largest frontier models. Now, AWS Trainium3 delivers the leading price-performance for high-performance AI training and inference at scale.
• EC2 Capacity Blocks for ML (2023): This new EC2 usage model further democratizes ML democratizes ML by making it easy to access GPU instances to train and deploy ML and generative AI models. You reserve the GPU capacity you need (initially P5 instances) for a future date and only for the duration you require. In November 2024, EC2 Capacity Blocks for ML added supported for provisioning in a matter of minutes and extending up to six months. Now, EC2 Capacity Blocks for ML supports P6-B300, P6-B200, P5e, P5en, P4d, P4de, Trn1, Trn2, and Trn3 instances in addition to P5.
• AWS Graviton5 (2025): Building on eight years of Graviton innovation since 2018, we previewed Graviton5 chips in AWS re:Invent 2025 and launched M9g and M9gd instances powered by Graviton5 and built on the sixth-generation AWS Nitro System. C9g and C9gd followed in June 2026. Now, Graviton5 features 192 cores, a 5x larger cache, and up to 33% lower inter-core latency, making it well suited for the growing demands of agentic AI workloads such as real-time reasoning, code generation, and multi-step task orchestration that require continuous, high-throughput CPU compute at scale.
• AWS Nitro Isolation Engine (2026): Customers wanted to see, not just hear from us, proof of workload isolation in the Nitro Hypervisor. The Nitro Isolation Engine is a purpose-built component inside the Nitro Hypervisor, harnessing formal verification to provide mathematical assurance that customer workloads are isolated from each other and AWS operators, pioneering a new standard for mathematically proven cloud security. This feature is also based on the sixth-generation AWS Nitro System which has continued to evolve since our introduction in 2017.

The foundation underneath it all
Despite two decades of innovation, the fundamental value proposition of Amazon EC2 has not changed. Customers use it to get secure, resizable compute capacity in minutes, pay only for what they consume, and scale on demand without long-term commitments. That same flexibility now extends to AI workloads at a scale no one anticipated in 2006.

EC2 remains the foundational compute layer of AWS. Amazon ECS, Amazon EKS, AWS Lambda, AWS Fargate, AWS Batch, Amazon EMR, Amazon SageMaker AI, and Amazon Bedrock ultimately run on EC2 capacity. Every architectural pattern customers have built over the past twenty years, from simple web servers to trillion-parameter foundation model training clusters, starts with a decision to launch an instance.

We made strong foundational decisions in 2006, and we left room for the service to grow. Twenty years later, that strategy of creating services that are minimal-yet-useful, launching quickly, and iterating rapidly in response to your feedback continues to guide how we build. The next twenty years of cloud computing will demand capabilities we have not yet imagined. Amazon EC2 will continue to be the foundation where your workloads run.

To learn more about Amazon EC2, visit the Amazon EC2 product page or check out what’s new with EC2.

— Channy

The post Happy 20th Birthday, Amazon EC2 appeared first on The NOKIA Blog.

I’ve experienced both scenarios. Sometimes, there’s no rhyme or reason why clients come and go. You can do everything right, and still a client looks elsewhere when it’s time for a redesign or new project. Perhaps they were swayed by a sales pitch. Or, a new person comes in and wants to shake things up. It’s an unfortunate part of this business.

Regardless, there’s still work to be done. Their website may need to be migrated to a different host. Credentials need to be created for the new freelancer. There are project assets and notes to share.

It’s an awkward situation at best. But never fear, I have some tips for making the transition as smooth as possible. Keep reading to learn the do’s and don’ts of working with that new (or old) developer!

Keep It Professional

Maybe it sounds obvious. However, it’s easy to become emotional when letting go of a project (and its revenue). The same thing applies when you’re the new developer. Some clients will paint an unfortunate picture of their previous agency. Don’t get caught up in it.

Odds are, neither you nor the other party is evil or inept. There are always two sides to a story, and you’ll probably only hear one of them.

As such, there’s no reason to be rude or unhelpful. Answer questions, document processes, and respond within a reasonable period of time. These are common courtesies that will speed up the transition. After all, no one wants this thing to drag on for too long.

The funny part is that you may encounter the same developer again. For example, I’ve gained and lost clients to the same local agency. It’s a reminder to keep it professional and avoid burning bridges.

We may be competitors, but we’re all in the same boat.

Get Paid Before Doing the Work

These transitions can be especially frustrating if a client owes you money. They may expect you to work with their new developer with a promise to pay later. Avoid this scenario at all costs!

A client who is always late with payment is unlikely to make good on their debt after you’re gone. As such, getting paid should be a condition for transferring the site to someone else.

Create an agreement (in writing) that outlines what you need from them before you can do the work. Don’t provide a single file or login until that condition has been met. This places the ball firmly in their court. If they want to move on, they’ll need to settle their outstanding debt. It’s a perfectly reasonable request.

If the client balks at the idea, you may need to bring a lawyer into the fold. It’s not ideal, but it may be the only way you’ll get your money.

Think Before You Share Sensitive Information

Sharing credentials is part of any website transition. There are logins for hosting, content management systems (CMS) like WordPress, and third-party SaaS applications. Not to mention API keys and software licensing details.

You may be tempted to send a laundry list of logins to the new developer. However, it’s worth taking a step back and ensuring you aren’t exposing yourself to risk.

If you manage a client’s hosting or domain name, for example, be sure that anything you share is specific to their website. You wouldn’t want someone to have access to other client data. If possible, create delegate accounts that provide only the necessary permissions.

Also, create a new administrator account for their CMS, rather than sharing your login. This takes you off the hook for any user activity or, worse yet, a hacked password. And make sure your account is deleted when you’re out of the picture.

Software licensing can be tricky, especially if they aren’t under your client’s name. If you have a developer license for a WordPress plugin, consider your comfort level with allowing a client to continue using it. It might be worth recommending they purchase a separate license.

If you’re inheriting the site from another developer, think about what you’ll need. Ask about all of the above and find out as much as you can. The goal is to avoid any surprises once you take over.

Transitions Are a Part of the Job

It’s safe to say that no one enjoys transitioning a website from one developer to another. It’s often a messy process and can raise your anxiety levels, regardless of which side you’re on. But there’s an opportunity to make the best of a difficult situation.

Maintaining a professional attitude is a must. Treat it as just another business transaction and do your best to leave personal feelings out of it. Work with integrity and aim to produce the best possible outcome.

It’s also important to protect your interests. A client who’s leaving must live up to their end of the bargain. Don’t allow them to walk away without paying their outstanding balance. Also, be careful about the information you share with a new developer.

The most positive aspect is the experience you’ll gain. Learning to manage clients coming and going will serve you well. Doing so will allow you to focus on the task at hand while avoiding all the negatives. That’s great, because you’re likely to need those skills again and again.

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post How to Work With Your Client’s Next (Or Previous) Developer appeared first on The NOKIA Blog.

During my time at AWS, I have always looked for opportunities to work with students. I have delivered over 50 talks at universities across the region, and watching the potential in the room is always a strong motivator. It reminds me of why I do this work, and that the students I meet today may well become our customers and collaborators tomorrow. That is why I am happy to open this week with Student Rewards on AWS Builder Center.

Rick Suttles published Introducing Student Rewards on AWS Builder Center, a new benefit for verified higher education students. When you verify your enrollment through SheerID and complete your Builder Center profile, you unlock 12 months of premium AWS Skill Builder access (900+ courses, hands-on labs, certification exam prep, and game-based learning). From there, you earn badges through actions on Builder Center: publishing articles, commenting, and maintaining engagement. At 7 badges, you unlock $10 in AWS Credits. At 14 badges, another $20 in credits. At 21 badges, you earn an AWS Foundational Certification exam voucher ($100 value).

This represents a commitment of over $500 million in resources during this back-to-school season, providing students with the training, tools, and certification needed to start building their careers in cloud and AI. Student Rewards is available to students 18 years or older and enrolled at accredited higher education institutions worldwide, subject to verification and applicable terms.

Verify your student status and start learning, earning badges, and unlocking rewards!

Last week’s launches
Here’s what else happened this week.

• A new AWS Local Zone in Las Vegas, Nevada – This new Local Zone supports Amazon EC2 C7i, M7i, R7i, and C8gn instances, Amazon EBS, Amazon ECS, Amazon EKS, Application Load Balancer, and AWS Direct Connect. AWS Local Zones are now available in more than 30 metropolitan areas worldwide. In addition, AWS added a fourth Availability Zone to the Europe (London) Region, delivering next-generation AI and ML capacity with Trn3 and P6 accelerated instances alongside general-purpose compute.
• Amazon EC2 Auto Scaling now supports batch instance termination – You can now pass up to 100 instance IDs to the TerminateInstanceInAutoScalingGroup API to terminate them as a batch, reducing the number of API calls needed to scale down your Auto Scaling groups. Batch termination is designed for workloads that need to rapidly scale down, such as AI/ML training jobs, container orchestrators, or event-driven architectures that spin up large fleets temporarily.
• AWS CloudShell now includes a built-in visual file editor – CloudShell now includes a visual file editor that you can launch directly from your shell session using a single edit command. The editor supports syntax highlighting, find-and-replace, multi-line selection, copy-paste, and undo-redo in a single browser session. Whether you are updating a deployment script, modifying an agent steering file, editing a CloudFormation template, or fixing a Lambda function, the editor provides a seamless edit-and-run experience without leaving CloudShell.
• Amazon Bedrock now supports SpaceXAI Grok 4.6 with cross-Region inference – Grok 4.6, a frontier model built for coding, agentic tasks, and knowledge work, is now available on Amazon Bedrock. The model runs on the bedrock-runtime endpoint with support for the Responses, Chat Completions, and Converse APIs, and works with existing account-level controls including model invocation logging, Amazon CloudWatch metrics, and cost itemization in AWS Cost Explorer.
• Amazon Bedrock expands API support and introduces cross-Region inference for OpenAI models – Amazon Bedrock now supports OpenAI GPT-5.6 models (Sol, Terra, and Luna) with the Responses, Converse, and Chat Completions APIs, and adds cross-Region inference. Geo cross-Region inference routes requests within a predefined geography (including new US Geo support with this launch), while Global cross-Region inference serves requests from any commercial AWS Region at a lower per-token cost.
• AgentCore payments is now generally available in Amazon Bedrock AgentCore – At general availability, AgentCore payments includes Quick Create for Coinbase credential provisioning directly within the AgentCore console, a curated Coinbase Bazar MCP server of pay-per-use x402 endpoints via AgentCore gateway, support for the Machine Payment Protocol (MPP), and the “upto” scheme in the x402 protocol for pay-per-inference and dynamic pricing use cases. To learn more, visit the AI Blog post.
• AWS Glue 6.0 delivers 30% price reduction and Iceberg v3 support – AWS Glue 6.0 is built on a fully modernized runtime, Apache Spark 4.1, Python 3.13, and Scala 2.13, delivering 30% lower pricing than previous AWS Glue versions. With Iceberg v3, Glue 6.0 adds the VARIANT data type with automatic shredding for faster reads on semi-structured data, deletion vectors for high-performance row-level updates, geometry and geography data types for spatial processing, and flexible schema evolution.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional posts you may find useful:

• Updates to your AWS Sign-In experience – AWS is gradually introducing updates to the sign-in and sign-up experience. The redesigned sign-in page introduces a unified email entry point for root users and customers using the new email-based sign-in method, while IAM users continue signing in with their account ID, username, and password. The page also includes sign-in options for customers whose AWS account was created using a supported identity provider (Google, GitHub, Apple, or Amazon.com). A redesigned session selection page simplifies viewing and managing multiple active account and role sessions. If your organization relies on browser automation or scripted workflows that interact with the sign-in page, review the post to understand how these changes might affect your configuration.
• In the works: AWS Builder Lofts in Berlin, Hyderabad, and São Paulo – My colleague Channy announced plans to open new Builder Lofts in three cities. Since the first Builder Loft opened in San Francisco in July 2025, it has welcomed more than 22,500 developers through its doors. Each new location will be a permanent community space offering free workshops, networking events, pitch nights, content creation spaces, and co-working areas. Berlin will focus on digital sovereignty and security-readiness, Hyderabad on AI and cloud-native architecture, and São Paulo on supporting Latin America’s developer ecosystem.
• AWS and Amazon WorkSpaces recognized as a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service – AWS has been named a Leader in the 2026 Gartner Magic Quadrant for Desktop as a Service (DaaS) for the third consecutive year, evaluated on Completeness of Vision and Ability to Execute. Gartner noted strengths in operations, geographic strategy, and overall viability. This is also the first year the evaluation includes Amazon WorkSpaces for AI agents, a capability that runs AI agents within the same desktop environment, security perimeter, and audit trail as human users.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

• AWS Summits – Free in-person events for builders and innovators to learn, connect, and explore the latest in cloud. Coming up: Zurich (September 2), São Paulo (September 3), Tel Aviv (September 10), and Dubai (September 30). You can also watch keynotes and sessions on the AWS Summits Global Livestream + On-Demand Hub. To access live and on-demand content for a particular Summit, you need to be registered for that event.
• AWS Community Days – Community-led conferences planned and delivered by community leaders. Upcoming events include Bolivia, Santa Cruz (August 29), Toronto, Canada (August 29), JAWS SONIC, Tokyo (September 5), Warsaw, Poland (September 8).

Visit the AWS Builder Center to meet other builders, contribute solutions, and find resources that help you keep building.

Summer is slowly coming to an end, and I am already planning a few days off in the coming months to keep me motivated through the rainy autumn ahead. I hope you are doing the same. Come back next week for more!

— Esra

The post AWS Weekly Roundup: Student Rewards on AWS Builder Center, Local Zone in Las Vegas, and more (August 24, 2026) appeared first on The NOKIA Blog.

Today, we are announcing the general availability of AWS Glue 6.0, delivering 30% lower pricing than previous AWS Glue versions and introducing full support for Apache Iceberg v3 features. AWS Glue 6.0 is built on a fully modernized runtime, Apache Spark 4.1, Python 3.12, and Scala 2.13, delivering faster performance.

With this release, AWS Glue provides the most complete Iceberg v3 implementation on any fully serverless managed Spark service, along with new capabilities that simplify ETL authoring, improve PySpark performance, and enable real-time streaming with single-digit millisecond latency.

What is new in AWS Glue 6.0
AWS Glue 6.0 delivers the complete Apache Iceberg v3 specification, built on Iceberg 1.11.0. The headline feature is the VARIANT data type with shredding support, which achieves faster query read performance compared to traditional string data type columns for semi-structured data.

With VARIANT shredding, you can store and query JSON, logs, and event data without flattening schemas, eliminating duplicate data copies, custom parsing code, and pipeline breakage when schemas change. This capability transforms how teams handle semi-structured data at scale.

Additional Iceberg v3 capabilities include:

• Geometry and Geography data types: Enable native spatial processing for GIS analytics, location intelligence, and geospatial data pipelines directly on managed Spark.
• Nanosecond-precision timestamps: Support IoT sensor data, scientific computing, and high-frequency financial workloads that require precision beyond standard milliseconds.
• Unknown type handling: Process data with unexpected or evolving schemas without pipeline failures, providing resilience against upstream schema changes.

AWS Glue 6.0 also includes most significant upgrade in Spark 4.1, the modern runtime engine:

• Spark declarative pipelines: Spark Declarative Pipelines introduces a simplified approach to ETL authoring. Data engineers declare transformations, specifying what data should look like, while the engine automatically determines execution order and optimization. This reduces the complexity of pipeline development and eliminates manual orchestration overhead.
• Arrow-native Python UDFs and UDTFs: AWS Glue 6.0 introduces Arrow-native execution for Python User-Defined Functions (UDFs) and User-Defined Table Functions (UDTFs). This eliminates serialization overhead between Python and the JVM, improving PySpark performance for complex transformations.
• Real-time streaming mode: For stateless streaming use cases, AWS Glue 6.0 introduces a real-time streaming mode that achieves single-digit millisecond latency. Built on Spark 4.1’s Real-Time Mode with Glue-optimized execution, this capability supports real-time event processing, low-latency data transformation pipelines, and time-sensitive data routing.

Getting started with AWS Glue 6.0
No API changes are required to use AWS Glue 6.0. You can select the new version using the existing --glue-version parameter in the create-job or update-job APIs through AWS Command Line Interface (AWS CLI), AWS SDK, AWS Glue Studio, Amazon SageMaker Unified Studio, and your preferred IDE.

To get started with AWS Glue 6.0 jobs in the AWS Glue Studio console, open the AWS Glue job and on the Job Details tab, choose the version Glue 6.0 – Supports Spark 4.1, Scala 2, Python 3. You can create new AWS Glue jobs on AWS Glue 6.0 to get the benefit from the improvements, or migrate your existing AWS Glue jobs.

To start using AWS Glue 6.0 on an AWS Glue Studio notebook or an interactive session through a Jupyter notebook, set 6.0 in the %glue_version magic. You can also upgrade existing jobs to Glue 6.0 using the Spark upgrade agent on AWS Glue Studio or use the auto-upgrade feature in their existing Glue jobs to automatically upgrade them to Glue 6.0.

To learn more, visit the AWS Glue 6.0 version detail and Migrating AWS Glue for Spark jobs to AWS Glue version 6.0 in the AWS documentation.

Now available
AWS Glue 6.0 is generally available today in all AWS Regions where AWS Glue operates. For Regional availability and a future roadmap, visit the AWS Capabilities by Region. If you want to call APIs, search documentation, find regional availability, and check troubleshooting about this new feature, try using the AWS MCP Server and plugins with your preferred AI tool.

You pay an hourly rate, billed by the second, for crawlers (discovering data) and extract, transform, and load (ETL) jobs (processing and loading data). For the AWS Glue Data Catalog, you pay a simplified monthly fee for storing and accessing the metadata. The first million objects stored are free, and the first million accesses are free. To learn more, visit AWS Glue Pricing page.

Give it a try in the AWS Glue Studio console, and send feedback to AWS re:Post for AWS Glue or through your usual AWS support contacts.

— Channy

The post AWS Glue 6.0 now available with 30% lower price and full Apache Iceberg v3 support appeared first on The NOKIA Blog.

In the early days of cloud computing, AWS supported intensive learning for builders in a physical space called the AWS Pop-up Lofts in cities worldwide. These spaces were accessible to startup entrepreneurs, developers, and others interested in learning more about AWS for events, meetings, and co-working. With the recent emergence of generative AI, AWS Gen AI Lofts provided pop-up style collaborative spaces across the world and immersive experiences for startups and developers.

We realized the need of permanent community spaces give students and developers a place to learn, connect, and contribute through hands-on experiences, community-led sharing, and technical collaboration. Since opening in San Francisco in July 2025, the first AWS Builder Loft has welcomed more than 22,500 developers through its doors, hosting hackathons, workshops, demo nights, and community-led events that bring the local tech community together under one roof.

Today, we are announcing plans to open new Builder Lofts in Berlin, Hyderabad, and São Paulo. Each location will be a permanent community space to offer free workshops, networking events, pitch nights, content creation spaces, collaboration/co-working areas, and event hosting for developers, students, or tech professionals who want to walk through the doors.

You’ll still be able to meet AWS experts there, but beyond that we further want to establish a home for local tech communities from AWS User Groups and AWS Student Builder Groups, to independent developer groups you’re already part of. As a tech community leader, you are welcome to request booking of our space to host your meetup at no cost.

Why three cities
The expansion reflects fast-growing developer cities which are important talent and innovation hubs for each region:

• Berlin: After launching AWS European Sovereign Cloud, we’re deepening our commitment to Europe’s developer community. Berlin’s Builder Loft will host educational sessions on digital sovereignty, hackathons, security-readiness workshops, and community meetups that connect Germany’s growing startup ecosystem with the broader European and global tech landscape.
• Hyderabad: The Hyderabad Builder Loft will give Indian developers a dedicated space to upskill on AI, explore cloud-native architecture, and connect with peers building the next generation of applications.
• São Paulo: Brazil’s cloud market is growing at 30% annually, and São Paulo sits at the center of Latin America’s tech boom. The Builder Loft will serve as a hub for the region’s developers, offering free programming in partnership with local communities, universities, and startup networks.

A typical week at the Builder Loft
The Builder Loft in San Francisco hosts four to eight community events weekly from technical deep dives on generative AI to startup pitch nights, from coding workshops for students to networking sessions that bring together developers from across the region.

The spaces are designed to be flexible. A training room fills with over 50 students on a Tuesday morning. By evening, it transforms into a demo stage where a startup showcases its latest prototype to a room of potential collaborators. On weekends, community groups host their own meetups.

What makes the model work is that it’s driven by the community itself. Local developers, meetup organizers, and tech leaders shape the programming. AWS provides the space, the infrastructure, and the support, but the energy comes from the builders who participate. Find upcoming events or request to host your own event at the Builder Loft San Francisco.

Stay tuned
We’ll announce Builder Loft openings in three cities in future blog posts, so stay tuned for updates! To learn more about Builder Lofts for details and to follow along for updates, read Rick’s blog post and visit the AWS Builder Loft page.

— Channy

The post In the works: AWS Builder Lofts in Berlin, Hyderabad, and São Paulo appeared first on The NOKIA Blog.

Last week, AWS contributors joined the OpenSearch and Valkey communities at Open Source Summit Korea 2026 and MCP DevSummit Seoul 2026 to meet open source developers and contributors. At the four-day event, community leaders and users of these Linux Foundation open source projects gathered to share knowledge, collaborate on solutions, and push the projects forward.

Leaders of the Korean OpenSearch communities volunteered to participate in the booth, and also had time to network and interact in the user group meetup.

OpenSearch is an open source, enterprise-grade search and observability suite that brings order to unstructured data at scale. On June 9, 2026, OpenSearch 3.7 introduced new tools designed to query, alert, and track SLOs across logs, traces, and metrics through a single interface and retrieve vectors up to 5.5x faster for improved search performance. Since July 30, 2026, you can run OpenSearch version 3.7 on Amazon OpenSearch Service for improvements in vector search performance, search relevance, and Query Insights.

Valkey is an open source high-performance key/value datastore that supports a variety of workloads such as caching, message queues, and it can act as a primary database. On May 19, 2026, Valkey 9.1 introduced a redesigned I/O threading model that improves throughput by up to 17% and reduces memory usage for strings under 128 bytes by up to 20%. Since June 23, 2026, you can run Valkey 9.1 in Amazon ElastiCache for node-based clusters, delivering higher throughput, improved memory efficiency, and stronger access control for multi-tenant workloads.

You can connect with AWS contributors at upcoming OpenSearch and Valkey community events.

Last week’s launches
Here are some launches that got my attention:

• Amazon EC2 application status checks: Amazon EC2 introduces a new status check that helps you detect and respond to application-level issues on your EC2 instances. With application status checks, EC2 monitors applications to detect issues such as a web server that has stopped accepting requests, a Docker daemon that is not running, an incorrect networking configuration, or a network interface that is no longer passing traffic. To learn more, visit the Application status checks documentation.
• AWS IAM role manager to set up IAM roles automatically: You can use a new role manager that automatically sets up the IAM roles your AWS services need. When you set up a supported service in the console, role manager creates a default role on your behalf, or reuses one that already exists in your account if it matches the required permissions. Role manager supports six AWS service consoles at launch. To learn more, read How AWS IAM role manager rethinks the starting point for IAM roles.
• OpenAI Daybreak available to eligible customers on Amazon Bedrock: Daybreak is the cyber defense initiative from OpenAI that gives defenders governed access to frontier AI for cybersecurity work. For most security teams, Daybreak Blue, powered by GPT-5.6 Sol, serves as the starting point across defensive workflows including vulnerability discovery, detection engineering, and incident response. Daybreak Red, powered by a new GPT-5.6 Cyber, is designed for advanced, authorized tasks such as vulnerability research, exploit reproduction, and mitigation development. To enroll, contact OpenAI or reach out to your AWS account team for guidance on eligibility. To learn more, read the AI Blog post.
• New foundation models in Amazon SageMaker JumpStart: We’re expanding the portfolio of foundation models available to AWS customers. These models address different enterprise AI challenges with specialized capabilities:

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional projects and news items you may find interesting:

• The deprecation of email validation in AWS Certificate Manager: ACM will discontinue support for email-validated public certificates by September 30, 2027. If you use email validation for your ACM public certificates, you need to migrate to DNS validation before that date. For Amazon CloudFront distributions, HTTP validation is also available.
• The next-generation AWS VPN Client with CLI support and admin controls: You can use a new AWS VPN Client built on OpenVPN3. With the new client, you get full backward compatibility with existing AWS Client VPN endpoints while delivering the automation capabilities and security posture that enterprise networking teams have been asking for.
• Oracle Exadata on Exascale for Oracle AI Database@AWS: ExaDB-XS brings Exadata-class performance and availability through a consumption-based model. With ExaDB-XS, you can scale compute and storage independently in small increments and pay only for what you consume.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events including AWS Summits and AWS Community Days. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.

That is all for this week. Check back next Monday for another Weekly Roundup!

— Channy

The post AWS Weekly Roundup: EC2 application status checks, IAM role manager, OpenAI Daybreak on Bedrock, and more (August 17, 2026) appeared first on The NOKIA Blog.

There’s been a lot of confusion and panic this week about “huge fines”, “drastic measures” and “sweeping new AI rules” in the EU. In reality, it’s a lot more narrow — and a lot more sensible. And mostly it’s about making AI more obvious when it actually needs to be obvious — especially for AI-generated content.

Starting from Aug 2, 2026, AI labelling is a legal requirement for any company that serves EU citizens. And similar to European Accessibility Act, it’s not limited to EU companies. It affects any company worldwide with EU operations as long as their AI output is used by people in the EU. Let’s see what exactly it means for us.

What Actually Needs Labelling

The goal of AI labelling is to help everyone exposed to AI content to recognize, in a clear and distinguishable way, that the content has been artificially generated or manipulated.

According to Article 50(4) of the AI Act, AI labelling applies to:

1. Deepfakes. Any image, audio, or video that resembles a real person, object, place, or event and would falsely appear authentic or truthful. Content that is not deceptively realistic generally doesn’t apply.
2. Chatbots and AI agents. Users must be informed if they’re not talking to a human.
3. Fully AI-written text. Specifically on matters of public interest, where there has been no human review or editorial work.
4. Emotion recognition and biometric categorization tools.

Both providers (who build or supply the AI system) and deployers (who use it) carry legal obligations. Similar to GDPR and EAA, a company doesn’t escape Article 50 just because it licensed an external AI tool from a third party.

However, it doesn’t mean that all AI-generated content must be explicitly labelled.

Not All AI-Generated Content Must Be Labelled

Beyond the use cases above, pretty much everything else — the vast majority of AI-assisted work — simply isn’t covered by new transparency rules. Most notably, the disclosure obligation does not apply where the AI-generated text has been reviewed and edited by a human, with a named person or entity taking editorial responsibility for it.

Some confusion circles around what exactly “public interest” means, where it starts and where it ends. On its own, it refers to health, safety, environment, economy, finances, politics, science, or culture. If AI-generated product claims touch upon them, the disclosure rule applies.

Some law firms recommend labelling realistic AI-generated illustrations or photos as a precaution for advertising, marketing and other commercial content. AI-generated product illustrations, photos, or posters do need a disclosure, as long as they resemble a real person, place, object, or event.

The Fine Line Between “Edited” And “AI-Generated”

But at which point does edited AI content stop being AI content? When a form is pre-filled with AI, but then a user edits it, is it still AI? EU Commission’s guidance is a little fuzzy. Small assistive edits — spellcheck, grammar, formatting, cropping, colour correction, and AI-generated translation — don’t count as AI generation.

AI-generated summaries, composite imagery, substantive rewrites, or adding and removing elements from a photo are considered AI generation. In practice, fine-tuning a sentence a person wrote is fine, but generating the sentence on its own requires a disclosure.

“A human skimmed it before publishing” doesn’t qualify as editorial review. The Commission is explicit that it needs to be substantive, with a named person responsible for the editorial control.

In other words, the fine line lies between intentional manual intervention and automated generation. The latter always has to be disclosed (exception: closed B2B environments).

AI Sparkles Probably Not Enough

As part of the Code of Practice, the European Commission has published an EU AI icon set. It’s a specific “AI” mark (similar to the AI label in Carbon Design System) — not the generic ✨ sparkle that many products use to signal AI. The signal must be “clear and distinguishable”.

The sparkle might be too ambiguous to signal AI clearly. Mostly because it’s often used to mean “AI-powered feature”, rather than “this specific content was generated by AI”. That’s the kind of signal EU guidelines are trying to rule out.

The Commission is explicit: using an icon “does not establish legal compliance by itself.” A barely visible icon, a note buried in the footer, or a label that flashes for a second are all not compliant.

The icon should be clearly visible, with a plain language label and accessible to assistive technologies. A safe bet is to pair any icon with plain text (“AI-generated”) — and it needs to persist when being reshared or downloaded.

In fact, the EU Commission also published Code of Practice on marking and labelling of AI content.

It Isn’t Just EU

It might feel like a yet another regulation coming from the EU, but in reality there are plenty of other similar regulations that emerged recently worldwide:

1. China has mandatory AI labelling since 1 September 2025. With visible tags and watermarked metadata.
2. California has SB 942, as amended by AB 853, which became mandatory on the exact same day as the EU rules (2 August 2026), deliberately timed to align.
3. South Korea has the AI Basic Act that took effect on 22 January 2026, widely cited as the first comprehensive national-level AI law to mandate deepfake labels. Fines are modest by EU standards (roughly $20K per violation), with a one-year grace period before enforcement bites.
4. India has an IT Rules amendment, in force since 20 February 2026. Platforms must label “synthetically generated information”, and takedown timing for most harmful deepfakes was cut to 3 hours.

All of these are signs of upcoming AI regulation that looks more like a pattern, rather than a coincidence. So if you’re shipping anything AI this year, it’s probably a good idea to have a conversation about what exactly is going to be AI-labelled, and what not.

Wrapping Up

One final note is that new EU AI transparency rules are much broader than US laws on AI disclosure, where certain state laws require disclosures for synthetic human performers, political advertising or specific AI applications.

None of this really deserves panic or confusion. It’s about a fairly simple idea that has been emerging worldwide at almost the same time:

When AI content could easily be mistaken for human content, creators must say so — in a way that is clear, obvious, and unambiguous. And parts of the UI that are AI-generated must be disclosed as such.

If anything, it will help people distinguish between AI slop and not AI — and everybody can only benefit from that.

Meet “Design Patterns For AI Interfaces”

Meet Design Patterns For AI Interfaces, Vitaly’s new video course with practical examples from real-life products — with a live UX training happening soon. Jump to a free preview.

Useful Resources

(yk)

The post New EU Guidelines For AI Labelling appeared first on The NOKIA Blog.

When front-end developers and UX engineers are tasked with building a web interface that feels tactile, bouncy, or destructive, the industry instinct is almost always the same: reach for a physics engine. Frameworks like Matter.js, Cannon.js, or custom WebGL solutions have become the gold standard for creating immersive, gamified websites.

When our team at Isadora Agency set out to build Stress Release, a digital stress-relief squeeze toy designed to let burnt-out creatives smash, stretch, and distort animated UI characters, we initially explored that route. The goal was to build a highly tactile experience where every click yielded a satisfying, squishy reaction.

But as we began prototyping, we realized something crucial: Physics engines produce plausible motion, but in our case, the animators produced intentional motion.

We didn’t need our characters to act like realistic rubber balls bouncing uncontrollably around a canvas. We needed them to react in very specific, highly designed ways. So, we scrapped the physics engine entirely.

In this article, we’ll break down how we built a real-time stress-relief squeeze toy without a single line of WebGL or Matter.js, relying entirely on programmatic Lottie state controls, DOM manipulation, and distance-based math.

The Design Requirements: Intentional Motion

Our core requirement for Stress Release was absolute deterministic control. Our animators had crafted bespoke .json Lottie files that required exact, frame-by-frame sequencing.

For instance, our ‘mega squeeze’ reaction required a precise 181-frame build-up followed by a specific release sequence. To honor this design, we needed an architecture that wouldn’t overwrite the animators’ crafted keyframes with algorithmic approximations.

The tighter the click-feedback loop (click → squish → score), the more you need deterministic frame control. By choosing programmatic state control using Lottie’s native API, we ensured that the interaction layer acted as a flawless trigger for the animation layer.

Creating Tactile Feedback: Mapping DOM Elements To Lottie States

Because our architecture relied on Lottie and the standard DOM, rendering is handled directly by the Lottie runtime, which plays the JSON-based vector animations as SVGs internally. We selected elements directly by ID and CSS class, driving their behavior using a combination of Lottie animation segments, CSS transforms, and click-event math.

To achieve a deeply satisfying “tactile feel” upon hitting a character, we used radial input mapping. The first step was converting the click from page coordinates into the character’s local coordinate space.

Every click was measured against the character’s center point, then translated into score, feedback intensity, and explosion placement:

// Character's center point in its own coordinate space
var x_center = parseFloat($("#playChar").width()  / 2);
var y_center = parseFloat($("#playChar").height() / 2);

// Click position relative to the character's top-left corner
var offset = $("#playChar").offset(); // document-relative position
var X = parseFloat(e.pageX - offset.left);
var Y = parseFloat(e.pageY - offset.top);

// Vector from center to click point
var a = parseFloat(X - x_center);
var b = parseFloat(Y - y_center);

Then we calculate the straight-line distance from the center of the click using the Pythagorean theorem:

var distance = Math.hypot(a, b);

That single number drives everything: the score, the feedback intensity, and where the explosion animation appears:

// Distance zones map to point rewards
if      (distance < 10)  givePts = 100; // bullseye
else if (distance < 40)  givePts = getRndInteger(70, 90);
else if (distance < 70)  givePts = getRndInteger(40, 70);
else if (distance < 100) givePts = getRndInteger(20, 40);
else if (distance < 120) givePts = getRndInteger(10, 20);
else if (distance < 145) givePts = getRndInteger(1,  10);
else givePts = 0; // miss

// Explosion Lottie repositioned to the exact click point
var shiftPosition = window.innerWidth < 1023 ? -20 : 200;
$("#explosionChar").css({
  "margin-left": a + shiftPosition + "px",
  "margin-top":  b + shiftPosition + "px",
});

// Fire the squish animation instantly
explosion.goToAndPlay(0);

The result is a concentric zone system — a perfect circle of scoring rings around the character’s center, similar to a dartboard. The visual complexity of the Lottie SVG is completely irrelevant to hit detection; the hitbox is always a clean circle. Critically, the explosion Lottie animation is repositioned to (a, b) — the same vector used for scoring, so it always appears exactly where the player clicked. This spatial accuracy creates the tactile “I hit that” sensation entirely through math and DOM positioning.

Interaction Handling: Controlling The Narrative

Because the experience used DOM-managed SVG elements, desktop clicks and mobile taps could be handled directly through native event listeners. This avoided extra raycasting or coordinate remapping layers, while keeping the interaction model aligned with how the animations were rendered.

Since the game requires a visual reaction at a specific point, Lottie handles all the squish and bounce feelings internally through its animation curves. Each character has a defined set of animation sections (idle loops, reaction frames, and end states) stored as frame ranges. When a click lands, we jump directly to the exact segment that matches the current game state:

// Animation sections defined as frame ranges per character
const play_segments = [{
  charId: 0,
  sections: {
    idle:     [0,  40],   // looping idle state
    squeeze1: [41, 80],   // light reaction
    squeeze2: [81, 120],  // medium reaction
    squeeze3: [121, 160], // heavy reaction
  },
  playOrder: ["squeeze1", "squeeze2", "squeeze3"],
  endAnimation: [161, 200]
}];

On every click, we advance through the play order and fire the next segment:

function stepAnim() {
  let p         = play_segments[0];
  let i         = p["playOrder"][curr_order_play];
  let playNow   = p["sections"][i];

  playChar.stop();                    // halt current segment immediately
  playChar.loop = false;              // no looping - play once and stop
  playChar.playSegments(playNow, true); // jump to exact frames, force immediately

  curr_order_play++;
  canPlayAnim = 0;                    // lock out further clicks mid-animation

  if (curr_order_play > p["playOrder"].length - 1) {
    curr_order_play = 0;              // cycle back to start of sequence
  }
}

When the segment completes, control returns to the idle loop:

playChar.onComplete = function() {
  canPlayAnim = 1;          // unlock clicks again
  if (!playEnd) playIdleState();
};

function playIdleState() {
  playChar.playSegments([0, 40], true); // return to idle loop
  playChar.loop = true;
}

And for the mega squeeze build-up, the bar loops on a specific frame range until triggered:

// Loop the "ready to release" frames until player activates
indikL.loop = true;
indikL.playSegments([181, 302], true);

// On activation - play the release sequence once
indikL.loop = false;
indikL.playSegments([96, 396], true);
indikL.goToAndStop(0, true); // hard reset after completion

The Responsive Benefit Of DOM Elements

Another major factor in our architectural decision was responsive behavior. Because we built Stress Release in the DOM, we bypassed the complexities of scaling bounding boxes and collision vectors across different devices.

We handled responsive resizing entirely through CSS variables. By recalculating CSS custom properties on every resize, the layout simply reacts to the updated variables, and the Lottie SVGs scale naturally inside their containers without losing their state:

const appHeight = () => {
  const doc = document.documentElement;
  doc.style.setProperty("--doc-height", `${window.innerHeight}px`);
  doc.style.setProperty("--doc-width", `${doc.clientWidth}px`);
};
window.addEventListener("resize", appHeight);
appHeight(); // run immediately on init

Mobile Performance Optimization: The Cost Of Lottie

While this architecture gave us total control over the art direction, it introduced a different challenge: file size.

Lottie JSON files can be heavy. We had 21 different character animations, plus multiple explosion variants that all needed to load. To ensure the experience remained fluid — especially on mobile devices — we implemented a few aggressive optimization strategies:

• Connection monitoring
  We tracked initial asset load time using performance.now() to detect slow connections and flag when load times exceeded 5 seconds.
• Sequential asset loading
  Rather than initialising all 21 character animations simultaneously, we load them in pairs using await, advancing only when each pair completes. This prevents a burst of simultaneous network requests and render work from blocking the browser on low-end devices.
• Aggressive memory management
  Instead of keeping our heavy explosion animations in memory, we destroy and recreate them on the fly. This trades a tiny instantiation cost for a much lower idle memory footprint.
• Dynamic quality reduction
  Quality reduction is a single API call applied immediately after each shelf character loads. The key is applying different quality levels depending on the character’s role in the scene:

// Shelf screen - 21 animations playing simultaneously
shelf = lottie.loadAnimation({
  container: document.getElementById("charShelf" + i),
  renderer: "svg",
  loop: true,
  autoplay: true,
  path: "assets/shelf/" + shelfFolders[i] + "/" + shelfFolders[i] + ".json",
});
lottie.setQuality(0.5); // 50% quality - reduces interpolation calculations
shelf.setSpeed(0.6);    // 60% speed - fewer frame calculations per second

// Play screen - single focused character
playChar = lottie.loadAnimation({
  container: document.getElementById("playChar"),
  renderer: "svg",
  loop: true,
  autoplay: true,
  path: chosenChar.url,
});
lottie.setQuality(1); // full quality - only one animation at a time

Conclusion: Choosing The Right Tech For The Design

When determining the stack for a gamified web experience, it is critical to let the design requirements dictate the technology.

Because our interactions required bespoke, highly controlled visual reactions, we opted for programmatic state control over emergent simulation. This decision empowered the animators to dictate the exact feel of the experience, leaving the code to do what it does best: listen, calculate, and trigger.

By mapping Lottie’s native timeline capabilities to the DOM, you can deliver incredibly rich, tactile user experiences while maintaining absolute control over the art direction.

Further Resources

Want to try implementing this yourself, or see exactly how it feels in the browser? Check out these resources:

• Play with the code.
  We have prepared a simplified demo example on CodePen demonstrating a character reacting to a click using playSegments().
• See the final product.
  Check out the live Stress Release site to see all 21 characters and the optimization strategies in action.
• Read the docs.
  Explore the official Lottie Web documentation to learn more about the player controls we utilized. Specifically, explore loadAnimation(), playSegments(), setSpeed(), and setQuality() — the four methods that power the entire interaction layer described in this article.

(yk)

The post Building Tactile UX: Honoring Intentional Design With Lottie appeared first on The NOKIA Blog.

Last week, we brought together AWS Heroes from around the world to connect, collaborate, and celebrate the builders who go above and beyond for the AWS community.

The AWS Heroes Summit, an invite-only annual gathering, brings global experts specializing in fields like AI, serverless, and containers together for direct collaboration, technical deep-dives, and feedback sessions with internal AWS product and service teams.

Day 1 started with an inspiring fireside chat from AWS CEO Matt Garman. From an insightful AMA with James Hamilton on Day 2 to breakout sessions from various product teams that sparked new ideas, our AWS Heroes excelled at sharing knowledge, lifting each other up, and turning conversations into collaborations. To learn more, read the attendee feedback on LinkedIn.

Last week’s launches
Here are some launches that got my attention:

• Web Search on Amazon Bedrock: Amazon Bedrock now enables OpenAI models (GPT-5.4, GPT-5.5, and GPT-5.6 Sol/Terra/Luna) to browse and retrieve information from the internet, allowing AI applications to access up-to-date information beyond their training data. This capability opens new possibilities for building AI agents and applications that can answer questions using real-time web content while maintaining data residency within your secured AWS environment with zero data egress. To get started, visit the AI blog post and the Amazon Bedrock User Guide.
• Runtime Instances on Amazon Bedrock AgentCore: You can now deploy and run AI agents on dedicated runtime instances through Amazon Bedrock AgentCore, providing more control over agent execution environments with predictable performance and cost. To get started, visit Sébastien’s blog post and AgentCore documentation.
• Vector search for Amazon DynamoDB: You can store and query vector embeddings alongside your existing data in DynamoDB without managing a separate vector database. DynamoDB already supports storing memory for AI agents, and with vector search you can now add semantic retrieval over that memory for agentic grounding, with predictable performance. To learn more, visit Esra’s blog post and Amazon DynamoDB Developer Guide.
• AWS Transform continuous modernization now generally available: This capability helps engineering teams analyze and remediate technical debt across source code repositories at scale. You can modernize mainframe and legacy workloads with an ongoing, automated approach rather than a one-time migration event. To learn more, visit Micah’s preview blog post. You can also try the AWS Transform Kiro Power and agent plugins.
• Up to 3,000 Mbps for AWS Lambda function bandwidth: AWS Lambda functions now support increased network bandwidth, enabling data-intensive workloads and faster communication between Lambda functions and other AWS services. This feature enables functions outside a VPC that are configured with 2 GB of memory or more to access network bandwidth that scales proportionally, from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional projects and news items that you may find interesting:

• Introducing Dogwood: Runtime Verification for AI Agents: AWS open-sourced Dogwood, a purpose-built governance language for AI agents to support Cedar policies and add temporal conditions. Powering Dogwood, Amazon Bedrock AgentCore introduced temporal policies whose decisions depend on the history of an agent’s actions within a session, not on the current request alone.
• AWS supports Agent Plugins: An Open Standard for Portable Agent Extensions: AWS announced support for Agent Plugins, an open source, vendor-neutral specification that gives AI agent extensions a common packaging format so you can package an extension once and ship it to any client, including Kiro, VS Code, Cursor, or any tool that implements the spec.
• Introducing Kiro Crew: Kiro Crew is a persistent, self-evolving workspace that keeps work moving, online or off, enabling collaborative multi-agent development workflows within the Kiro IDE. It’s built for engineering work that goes beyond a single chat session, and spans repos, tools, and days. You can run several efforts in parallel or hand work to subagents that report back, so nothing waits in line.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events including AWS Summits and AWS Community Days. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.

That is all for this week. Check back next Monday for another Weekly Roundup!

— Channy

The post AWS Weekly Roundup: AWS Heroes Summit, Web Search on Amazon Bedrock, Dogwood, Kiro Crew, and more (August 10, 2026) appeared first on The NOKIA Blog.

The WordPress project is slowly but surely inching toward responsive block settings. Version 6.9 introduced the Block Visibility feature, allowing you to temporarily disable a block without deleting it from a post. WordPress 7.0 took it a step further by adding options to hide a block based on device.

Perhaps it’s a niche feature. But it’s also quite handy for targeting mobile or desktop users with specific blocks. And it’s also a gateway to more responsive controls landing in WordPress 7.1.

Today’s tip will show you how easy it is to show or hide a block based on a user’s device. Here we go!

Sample Project: Simplify a Hero Area for Mobile Users

Here’s a common scenario: Your website has a large hero area, complete with a high-resolution image, text, and a call to action (CTA). It looks great on a desktop device but is clunky on a phone. The image is too big, and there’s too much text for users to digest. What to do?

The responsive Block Visibility controls will make this a piece of cake. We’ll create two hero areas – one for desktop and another optimized for mobile. The result will be a better user experience for everyone.

Step 1: Create Desktop and Mobile Hero Areas

The first step is to create the two hero areas for our page. We’ll grab one from the WordPress Block Pattern library and see what we can do with it.

Our desktop hero area is beautiful on the big screen! It should also work well on tablets, such as an iPad. However, it may be overwhelming for mobile users.

Let’s simplify. We duplicated the desktop hero and made a few changes:

• We replaced the image with a cropped version that is optimized for smaller screens.
• We centered the text and CTA.
• We replaced the three columns of text with one, shorter passage.
• Finally, we tightened up the spacing to reduce scrolling.

The mobile hero offers the same immersive look without the extra bulk.

Step 2: Assign Hero Areas to Their Respective Devices

As of now, our page has two hero areas, each contained within a Group block. The next step is to set one of them to display on desktop/tablet devices, and the other on mobile. We’ll use the Block Visibility feature to make it happen.

Desktop/Tablet Devices:

• Click on the Desktop Hero block we created.
• Click on the Options menu (⋮) and select Hide Block.
• Choose the Hide on Mobile option.
• Click the Apply button and save the page.

Mobile Devices:

• Click on the Mobile Hero block we created.
• Click on the Options menu (⋮) and select Hide Block.
• We’ll choose two options this time: Hide on Desktop, Hide on Tablet
• Click the Apply button and save the page.

You may notice that the mobile hero no longer displays on the Block Editor canvas. That’s the desired result, as it won’t be in the way when working in Desktop preview mode.

Switch to Mobile preview mode, and you’ll see the opposite effect. The desktop hero is hidden, allowing the mobile version to take over. You can edit these blocks when in the appropriate preview mode.

Note that you can also view and edit these blocks using the Document Overview (List View) feature (Shift+Alt+O). Select the block, click on the Options menu (⋮), and select Show from the menu. You can hide it again once you’re finished editing.

Oh, and be sure to test on different devices! It’s not enough to shrink your desktop’s browser window. You can use your browser’s dev tools to emulate a mobile device if you don’t have one handy.

Use Different WordPress Blocks on Different Devices

It’s often the little extras that make the biggest difference. Targeting different devices via the Block Visibility feature is a prime example. Its release didn’t draw much fanfare. However, it makes WordPress more flexible for designers.

Before WordPress 7.0, we’d have to work around this limitation. That could mean installing a specialized plugin or writing custom CSS rules in a theme. Now, we’re only a few clicks away from choosing which blocks display on a given device.

The feature saves us time, improves the user experience, and won’t hog server resources. Most of all, it’s a sign of things to come for WordPress.

here. He recently started a writing service for WordPress products: WP Product Writeup. He also has an opinion on just about every subject. You can follow his rants on Bluesky @karks.com.

Read more articles by Eric Karkovack

The post How to Hide WordPress Blocks Based on Device appeared first on The NOKIA Blog.

Our collection offers a range of filters to give your photos soft palettes, gentle fades, and other quaint effects. From landscapes to portraits, you can create an authentic vintage aesthetic with just a few clicks.

These actions can help recreate the look of a vintage postcard or an old family album or bring the style of a bygone era to your modern images.

This collection has the best Photoshop actions and presets to streamline your workflow and help you achieve the vintage look you want. Find the perfect action for your next project below!

If you’re looking for more vintage or retro resources, you might like our free collections of Photoshop brushes, vector templates, or fonts.

Light leaks, date stamps, and more! This retro Photoshop action collection has everything you need for nostalgic photographs. You’ll get 15 retro film Photoshop actions inspired by vintage camera styles, ten light leak overlays, and more. If you love retro, add this pack to your kit!

Capture stunning shots and add indie charm to them with these Photoshop actions. This collection includes 17 actions, over 110 gradient maps, and 21 PNG light leak effects. Perfect for creating a nostalgic atmosphere for your portfolios, magazines, and social media images.

With these Photoshop actions, you can transform your photos into watercolor art or give them a vintage atmosphere. This set includes Photoshop brushes, patterns, 20 actions, and everything you need to create vintage. With one click, you’re ready to go!

With these Photoshop actions, you will get authentic retro contrasts and vignetting. This set includes ten actions to create an analog film atmosphere in your images, perfect for portfolios, magazines, and social media. You’ll love the subtle retro tones.

All you need to travel back in time is Photoshop and these vintage actions. This collection helps you transform your standard photos into vintage works of art. You can fine-tune the actions’ details to get old camera effects or create a full-on masterpiece.

From the faded ’60s to the vibrant ’70s, this set of retro Photoshop actions has every old-school aesthetic you’d ever want! It includes seven editable Photoshop actions, textures, and light leak overlays. Easily create a beautiful lookbook, image, or poster!

Elegant and authentic, these retro text effects for Photoshop are perfect for your next project. Drawing inspiration from the 50s and 60s aesthetics, in this pack, you’ll get ten unique 3D styles, and they’re 100% editable.

Create Polaroid photos without a Polaroid camera! This Photoshop generator will give you a vibrant Lomography effect that replicates the original styling of Polaroid photos. You can also choose a colorful frame and add special effects like fisheye.

Transform your photo into a work of art with this vintage art Photoshop action set. The action pack also includes brushes, splashes, and color grading, so you can easily give your modern photos a vintage look.

Perfect for wedding photographers, these vintage Photoshop actions will give your clients an unforgettable wedding album. They will give your original shots a soft and gentle look and feel.

Give your photos a retro touch with these light leak Photoshop presets. They’re ideal for retro-themed photos and add vintage charm to adventure shots. You’ll get 25 light leak effects to work with.

You don’t need to travel back in time with your camera to create stunning retro videos. Use these animated retro vintage film Photoshop actions. You’ll get 24 color options with animated light leaks, camera shakes, and other effects.

These stunning photo effect actions allow you to create vintage photos and graphics quickly. Download them to add vintage charm with just a few clicks. They’re perfect for stylish fashion editorials and engaging social media posts.

Stylish and authentic, these retro and vintage text Photoshop actions are perfect for old-school typography. You’ll get 18 high-quality Photoshop actions that offer creative text effects for a variety of projects, from flyers and posters to cinematic titles and covers. You can easily use them via smart objects.

Create gorgeous graphics with these vintage text effects. Nine styles are included, from old-school cafe signs to funky 3D text effects. The smart objects system in Photoshop allows you to easily add your own content with just a few clicks.

Get perfect toning with these vintage and retro color effects for Photoshop! This pack includes 21 effects, as well as creative effects like vignettes, noise effects, and more.

Turn your original photos into vintage art with this retro Photoshop action. In just a few clicks, you can transform your images into masterpieces with vintage splashes, typography, effects, and colors.

These vintage film Photoshop actions are perfect for professional photoshoots. You’ll get ten actions to create a vintage atmosphere while retaining the beauty of your original shots. They have been inspired by analog films such as Agfa, Fujifilm, and Kodak.

Create retro prints with these Photoshop actions. Inspired by retro art, this collection includes brushes and patterns to create unique effects. All you have to do is brush over the parts of the image you want to transform and play the action.

How to Install Photoshop Actions

1. Open Photoshop: Launch Photoshop.
2. Locate Actions Panel: In Photoshop, you’ll find the Actions panel. You can usually find it by going to the Window menu and selecting Actions.
3. Load Actions: Go to the Actions panel. Click on the little menu icon (usually represented by three horizontal lines or dots) at the top-right corner of the panel. From the dropdown menu, select Load Actions. A file dialog box will appear. Navigate to the location where the .atn file is saved, select it, and click Load.
4. New Actions Set: Once you’ve loaded the actions, you’ll see them appear in the Actions panel as a new set. The set will have a folder icon and the name of the action set.
5. Apply Actions: To use the installed actions, open an image you want to edit in Photoshop. Then, select the action you want to apply from the list in the Actions panel.
6. Run the Action: Click on the action name, and you’ll see the play button at the bottom of the Actions panel. Click this button, and Photoshop will automatically apply the selected action to your image.
7. Adjust Settings: Some actions may have customizable settings. If so, double-click on the action name to access these settings and make adjustments as needed.
8. Save Your Work: Once you’re happy with the edits made by the action, make sure to save your image using the File menu in Photoshop.

A Touch of Retro & Vintage Charm

This collection of Photoshop actions has everything you need to give your photos and graphics a retro or vintage touch.

Versatile and user-friendly, these actions will streamline your workflow and help simplify the editing process. With just a couple of clicks, you can transform your work into beautiful, timeless art.

More Photoshop Actions

Read more articles by Paul Andrew

The post 20+ Best Photoshop Actions for Retro & Vintage Photo Effects appeared first on The NOKIA Blog.