Resolví un bug: era porque 7.5 % 2 da 1.5 en JavaScript y 1 en PHP. Y me quedé pensando: ¿cuántas diferencias más habrá de este tipo? Así no me vuelven a agarrar desprevenido.

Como no encontré una lista con las divergencias que estaba buscando, hice lo que haría cualquier persona razonable: puse ocho IAs a laburar en el tema.

Hasta el momento, encontraron 143 divergencias semánticas… solamente en los tipos de datos que maneja JSON: números, strings, arrays, maps, booleanos.

Por ejemplo:

• Math.round(-2.5): -2 en JS y Python… -3 en PHP
• Math.round(2.5): 3 en JS y PHP… 2 en Python
• "😀".length: 2 en JS (UTF-16)… 1 en Python… 4 en PHP (bytes)
• "10" < "9" → true en JS y Python… false en PHP (compara numéricamente)
• sort(): [1, 10, 2] en JS (ordena alfabéticamente)… [1, 2, 10] en Python
• split(""): ["a","b","c"] en JS y PHP… ValueError en Python
• "a" || "b": "a" en JS y Python… true en PHP

Y eso sin mencionar nuestro querido 0.1 + 0.2 = 0.30000000000000004 en todos los lenguajes con float de 64 bits.

La lista completa está acá (es como un video recopilación de accidentes de tránsito): https://github.com/sbustelo/JSOL/blob/main/docs/10_dev/EXTENDING-SEMANTIC-PARITY.md

Y si quieren, dénse una vuelta por el resto del repo. Es como JSON, pero para lógica de negocio. Ya se compila a sí mismo en JS y PHP, ya irán saliendo otros.
Demo: https://jsol.bustelo.com.ar/

Quizás les parezca una aberración, quizás les parezca útil… ya me dirán :)

How stupid do you think they think we are? Discuss

When validating interfaces, UX Research often relies on compliance metrics (like WCAG contrast ratios or APCA perceptual contrast) as a proxy for readability. However, these models primarily measure detectability—the immediate ability to distinguish text from background. They fail to account for the longitudinal, physiological realities of sustained human reading.

Through IPAX (an ongoing research initiative evaluating the gap between compliance and actual user adoption), we’ve been analyzing why legally compliant color pairs often fail empirical usability testing.

Standard models treat high contrast as an absolute good. But in real-world testing, extreme contrast introduces severe ergonomic penalties that degrade user experience over time, particularly for users with astigmatism, presbyopia, or glare sensitivities.

To build a more valid model for design validation, IPAX introduces algorithmic penalties for variables that traditional accessibility metrics ignore:

• Halation & Glare: Accounting for display emission effects and light scatter in the human eye.
• Chromatic Fatigue: Measuring the sensory load on cone adaptation and opponent channels under high-saturation stress.

A clear example of this metric divergence is standard black text (#000000) on a bright yellow background (#FFFF00). It achieves maximum compliance scores under both WCAG (AAA, 19.5:1) and APCA (Lc 101). Yet, in sustained reading tests, it triggers high visual fatigue and discomfort for millions of users. IPAX adjusts this mathematically, bringing the final score down to accurately reflect its actual usability.

I’m currently opening this up for discussion and fine-tuning the experimental coefficients. How do your research teams validate long-form reading comfort beyond standard compliance checks?

(Note: I’m presenting the full methodology, experimental data, and frameworks next week. To respect the sub's rules on promotional links, I will leave the link to the full abstract and presentation details in the comments below).

Every day on LinkedIn and Twitter, we see the same lazy trend: a static image showing two screens side-by-side. One has a red "X", the other a green checkmark. "UX Secrets Revealed!" or some other click-baity caption.

Interaction design cannot be judged by looking at a snapshot. Yet we are drowning in static design principles masquerading as deep usability critique.

Frustrated by this, I decided to build live, interactive micro-apps to revisit a classic example by Jef Raskin from his seminal book, The Humane Interface.

I built two completely different interfaces designed to achieve the exact same utility: converting temperatures from Celsius to Fahrenheit, and vice versa.

• UI A: The "Boring" UI (A standard numeric input/calculator style grid).
• UI B: The "Cool" UI (A highly visual, interactive fluid thermometer).

The Experiment (Try it yourself)

I invite you to test your own biases.

1. Open the two UIs, side by side.
2. First look: Just stare at them for 5 seconds. Which one do you honestly like better? Which one feels more "engaging"?
3. Now, perform the actual work: Try using both tools to convert this exact list of values as fast as you can: 21°C, 70°F, -20°C, -100°F 37.5°C, 98.6°F , 36.80°C, -12.5°C, 101.20°F, -100 F, -20 C, 80 F.
4. After doing the work: Which interface do you prefer now?

I’d love to hear your thoughts!

• edit: fixed the list (markdown swallowed it)

Back in 1986, on a CZ-Spectrum (a local Argentine clone), I fell in love with Art Studio. Decades later, I wanted to revisit my retro pixel art roots on an emulator, but I hit a wall: I didn't have the Lenslok prism to get past the copy protection.

Simon Owen built a brilliant C++ Windows utility (LensKey) to solve this years ago. Since I'm on a macOS environment and wanted something without dependencies, I extracted his original mathematical transformation matrices and ported the whole thing to a modern, client-side web.

It's completely free, runs locally in your browser, and handles the screen capturing workflows smoothly.

You can use it here directly: https://www.bustelo.com.ar/apps/lenskey-web/index-en.html

Or check the source code on GitHub: https://github.com/sbustelo/lenskey-web

Huge thanks to Simon Owen for the original reverse engineering. Hope this helps someone else trying to play Elite, Tomahawk, or Art Studio today :)

Accessibility has been at odds with design practice. I’m building the fix, but I need your help to bring it forward.

I’m Santiago Bustelo. I’ve spent my career volunteering for the Design community, including serving as a regional coordinator for IxDA since 2010. I’ve also helped drive Accessibility Laws because I believe technology should empower, not exclude.

I’m not here to sell a product; I’m a colleague who has spent decades trying to improve our craft and would like to finish what I started.

For decades, I’ve seen accessibility treated as a bureaucratic checklist that designers resist because it’s forced upon them and leads to poor design outcomes.

To solve this, I spent months building IPAX.

It’s not another 'contrast checker'. It’s a model that rewards great design instead of just legal compliance, integrating WCAG, APCA, and ergonomics like halation, glare, and chromatic fatigue.

The model is solid and the first tools (Sandbox, Font checker, Color System designer) are live (please forgive the experimental settings and rough corners). But I’ve hit a financial wall and can no longer carry this development alone.

I’m currently looking for sponsors, research partners, or grants to close the gap between accessibility theory and real-world design practice.

If you work at a university, an organization, or a company that actually gives a damn about the European Accessibility Act (EAA 2025) and wants to support a tool that makes compliance operationally transparent, let's talk.

And if you're just a curious UX colleague, check it out: icograma.com