Las webs de agencias dicen «somos técnicos» con un párrafo y una foto de stock. Nosotros preferimos demostrarlo: pusimos una consola de verdad en mitad de la home y un presupuestador que reacciona a cada clic. Este post cuenta cómo se construyeron las dos piezas y qué aprendimos de ver a la gente jugar con ellas.
Una terminal de verdad, no un mockup
La sección «Bajo el capó» es un intérprete de comandos escrito en vanilla JS: historial con ↑↓, autocompletado con Tab (con texto fantasma), chips de acceso rápido y una secuencia de boot con guiño incluido: humo comercial… [not found]. Los comandos responden con contenido real: servicios, casos con enlaces, stack, contacto.
El detalle que más gusta es el easter egg: escribe matrix y una lluvia digital en cobalto/cyan (con glifos de INTERVOLUTIONS colados) toma la pantalla durante unos segundos. Canvas 2D, cero librerías, y pausado en cuanto sales del viewport.
Astro scopea los estilos por componente, pero las líneas que crea el JS en runtime no llevan ese scope. Solución: estilos globales con prefijo .term-*. Veinte minutos de depuración que te regalamos aquí gratis.
El presupuestador: marketing que se juega
El CTA clásico («¿hablamos?») pedía fe. El nuevo pide 30 segundos de juego: eliges qué construyes, le sumas poderes y un panel en vivo monta tu plan: fases que se encienden, semanas y horquilla con interpolación numérica, y un medidor de ambición que va de MVP ágil a Buque insignia.
La gracia está en el cierre del bucle: «Quiero este plan» llega al formulario de presupuesto con el plan ya escrito en el mensaje. El visitante llega al formulario con el plan ya escrito y la conversación empezada. Menos fricción para él y un brief mucho mejor para nosotros.
- Números con tween y pop: los cambios se sienten, no se leen
- Chispas de partículas en cada clic (5 nodos DOM, 600ms de vida)
- Gauge SVG con stroke-dashoffset: barato y suave
- Todo respeta prefers-reduced-motion
La mejor prueba de que sabemos hacer productos interactivos es que nuestra web lo sea.
Nota interna del proyecto
Una consola tiene que funcionar con teclado o no es una consola
El riesgo de una pieza como ésta es hacerla para la demo y no para usarla. El campo de entrada es un input de verdad, con foco visible, y responde a lo que espera cualquiera que haya usado una terminal: flechas para el historial, tabulador para completar, Escape para limpiar. Nada de capturar pulsaciones en document y adivinar.
La salida se anuncia en una región viva, para que un lector de pantalla lea la respuesta al ejecutar un comando en vez de dejar al usuario sin saber si ha pasado algo. Y todo lo que la consola cuenta —servicios, casos, contacto— está además en la página como contenido normal: la terminal es otra forma de llegar a lo mismo, nunca el único camino.
Lo que cuesta en bytes, y cuándo se paga
Dos piezas interactivas son JavaScript que alguien tiene que descargar. La disciplina está en cuándo. El intérprete no forma parte del guion inicial: la portada pinta primero y el módulo de la consola se carga después, o directamente cuando la sección se acerca al viewport. Si nadie baja hasta ahí, nadie lo paga.
El presupuestador va al revés, porque está más arriba y es la pieza que convierte, pero tampoco bloquea el pintado. Y las dos son JavaScript propio sin librerías: no es una medalla, es que una dependencia de treinta kilobytes para animar un número es exactamente el tipo de decisión que hace lenta una web sin que nadie sepa por qué.
El movimiento se apaga entero cuando toca
La lluvia de la matriz, las chispas de los clics, la interpolación de los números y el medidor: todo eso desaparece con prefers-reduced-motion. No se ralentiza, se quita. Y la información se queda: el número final aparece directamente en su sitio, el medidor se dibuja en su posición, la consola contesta sin animación de escritura.
Además, la lluvia se pausa cuando la sección sale de la pantalla y cuando la pestaña deja de estar visible. Un canvas animado en segundo plano es batería que se va sin que nadie lo esté mirando.
Abrir la página con el ordenador limitado a la cuarta parte de su velocidad. Si con eso la interacción sigue respondiendo, en un móvil de gama media también.
Cuándo NO poner algo así
Esto funciona en la web de quien vende desarrollo, porque la pieza es el argumento: demuestra la capacidad de la que habla el texto. En la web de una asesoría, de una clínica o de una tienda del pueblo sería ruido caro, y lo diríamos igual de claro.
La pregunta antes de construir algo interactivo es siempre la misma: ¿esta pieza acerca al visitante a la acción que importa, o le da algo más entretenido que hacer que convertirse en cliente? Si es lo segundo, no se construye.
