Slides de Immpulso

Decks HTML autocontenidos, con el mismo lenguaje visual del sitio de Immpulso. Se presentan desde el navegador, en pantalla compartida, y se dejan publicados como material para quien asistió.

Lo primero: el tono

Esto es lo que más se ha corregido. Léelo antes de escribir una sola slide.

Jero narra, el deck no. El deck pone lo que es, en tono neutro, animado. El relato lo pone él hablando. Un deck que cuenta una historia le estorba.

Prohibido, sin excepción:

• Títulos de dos partes con dos puntos y remate: LA JUGADA: PEDIR BIEN. Le parecen horribles.
• La construcción no es X, es Y / es X, no Y. Nunca.
• Marcos de reloj: 8:00 a. m., 10:00 a. m., "a media mañana". Se siente horrible.
• Narrar al personaje: "Carolina abre el correo y suspira". Ni una línea.
• Cifras sueltas como frase de efecto: "Novecientos millones por semana." No le gusta.
• "Escríbele a Martin" o cualquier llamada a la acción que suplante su discurso.
• Logos de clientes inventados. Precios en piezas públicas.

Lo que sí:

• Una idea por slide, dicha de frente. Todo lo que sabe de tu tarea es lo que le pegaste.
• Menos palabras siempre. Si cabe en seis, no van doce.
• Cada palabra tiene que ganarse el espacio del slide: textos grandes, sin relleno.
• Español de Colombia, sin voseo. Usted o tú, coherente dentro del deck.
• Los datos van verificados contra la fuente antes de escribirlos. Si el número no se pudo comprobar, no entra.

Detalle: todo más grande de lo que parece necesario. El deck se ve en el celular y desde el fondo del salón. Si en el monitor se ve cómodo, está pequeño.

Y el celular no es el caso raro: la gente entra por el QR durante la sesión y vuelve después. Es donde más ojos va a tener el deck. referencia/movil.md antes de dar nada por terminado.

Primero: cuál de los dos decks

Hay dos maneras de armar esto y la decisión define todo lo demás.

• Deck fluido — medidas en clamp(), una slide por toque, se lee bien en el celular. Para una sesión larga con kit, QRs y ejercicios. Parte de plantilla/_armar-referencia.py.
• Deck de pasos — lienzo fijo de 1600 × 900 que la página escala, y cada toque hace entrar un elemento con su frase de guion debajo. Para una propuesta o un pitch que él va argumentando en vivo. Parte de plantilla/_propuesta-referencia.py y lee referencia/pasos.md.

Regla simple: si él va a hablar mientras la slide se construye, es de pasos. Si la gente la va a leer sola después, es fluida.

Cómo se construye

Un solo archivo Python es la fuente de verdad. Genera el deck, el kit de materiales y la portada del subdominio. Nada se edita a mano en el HTML.

proyecto/
  _armar.py        → index.html, 1/index.html, kit/index.html
  _barrido.js      → verifica el deck en varias resoluciones
  img/             → fotos, piezas, QRs generados
  kit/archivos/    → PDFs, .txt, .xlsx, .zip descargables

El corazón de _armar.py es una lista S de diccionarios, uno por slide:

S = []
def s(**k): S.append(k)

s(tipo='titular', luz=0, fondo='negro', cap='El perro espía',
  rotulo='ChatGPT',
  titulo='Lo más valioso es que el perro ya habla.',
  bajo='Hoy: cómo pedirle bien, y cómo comprobar lo que dice.',
  notas='La idea que sostiene toda la sesión.')

notas alimenta la ventana de notas del presentador. Escríbelas siempre: son para él, en vivo, y le dicen qué hacer, no qué leer.

Pasos:

1. Lee referencia/copy.md y define el guion en frases, antes de tocar código.
2. Parte de plantilla/_armar-referencia.py — el generador completo del deck de la sesión 01, con los 82 slides, el kit, los QRs y el zip. Quita el contenido, deja la maquinaria, llena S.
3. Genera: python3 _armar.py
4. Verifica en las cinco resoluciones (una por comando): 1920×1080, 1440×900, 1280×720, 390×844 y 360×740. Cero FUERA, PISA, CHOCA, ROTAS, APILADAS.
5. Revisa la hoja de contacto en _capturas/<res>/hoja.jpg con tus propios ojos antes de decir que está listo.
6. Despliega y comprueba en vivo lo que se descarga y lo que se ve.

Referencias

• referencia/copy.md — el tono, con ejemplos aprobados y rechazados.
• referencia/sistema-visual.md — colores, tipografía, CSS base pegable.
• referencia/tipos-de-slide.md — el catálogo de tipos y sus campos.
• referencia/movil.md — las cinco reglas del celular. Léelo, no lo dejes para el final.
• referencia/mecanica.md — navegación, notas, reloj, cargador, barrido.
• referencia/pasos.md — el deck de lienzo fijo: la mecánica de pasos, el guion por paso, y las reglas de cuando quince piezas comparten documento.
• referencia/movimiento.md — el catálogo de animaciones que él ya puntuó, con la regla que explica las notas altas y las quince mecánicas probadas. Léelo antes de diseñar cualquier movimiento.
• referencia/taller.md — cómo escribir quince o veinticinco slides con agentes sin perder el trabajo a mitad de camino.
• referencia/comercial.md — qué vende Immpulso, con los precios de ahora. Para cuando la pieza es una propuesta y no una clase.
• referencia/verificar.md — los tres verificadores y los defectos que ya han aparecido.
• referencia/materiales.md — kit descargable, QRs, prompts en RAFAT.
• plantilla/ — los dos generadores de referencia, el CSS base, el de deck y el del lienzo de pasos (marca-pasos.css), los tres verificadores (_lint.py, _ver.js, _verdeck.js), la espec y los encargos que lee el taller de agentes, y las dos herramientas de decisión (_puntuar.py para elegir ejercicios, _variantes.py para resolver una slide rechazada).

Reglas que ya costaron caro

• Nada de avanzar con clic. Solo teclado. Un clic accidental en vivo saltaba slides.
• Las imágenes bajo /img/ no se cachean para siempre. Si cambias el contenido de un QR sin cambiar la ruta, el navegador sirve el viejo. ?v=<md5> y max-age=300.
• Los enlaces del kit van con ruta absoluta desde la raíz (/kit/archivos/x.pdf). Relativos desde una URL sin barra final resuelven mal y dan 404.
• El HTML se sirve con max-age=0, must-revalidate. Si no, él abre la versión vieja y reporta que algo no funciona cuando ya está arreglado.
• El barrido espera 2 s por slide. Medir durante la animación de entrada da choques falsos.
• Nunca pongas display sobre una .s sin .viva. Una regla de media query que lo haga saca esa slide del display:none y pinta el deck entero encima de sí mismo. El barrido lo caza con APILADAS, pero solo si corres el móvil.
• align-content:center desborda por arriba. Va safe center, siempre: si no, el título de una slide larga se esconde debajo de la barra y no se alcanza.
• Las listas de anclas y de QRs se verifican contra las slides al generar. Una lista hardcodeada que quedó desactualizada rompió once QRs sin avisar.
• Toda regla de CSS de una pieza empieza por su #id, incluidas las de dentro de un @media, y sus @keyframes llevan el id en el nombre. Cuando quince piezas comparten documento, una regla suelta se lleva a las otras catorce. Es lo que más rompe y solo se ve montado.
• Escribe el guion antes de diseñar los pasos. Una animación que va por su cuenta compite con quien habla; una que entra cuando él nombra esa idea la subraya. Ese es todo el punto del modo de pasos.
• Antes de escribir el CSS, pregúntate qué objeto es la slide. Si la respuesta es "el texto", vuelve a empezar: lo que él puntúa alto siempre tiene un cuerpo que pesa, llega y se frena.
• .notas[hidden]{display:none} explícito. Un display:grid en la clase gana sobre el hidden del navegador y las notas del presentador salen proyectadas.
• Nunca inventes una cifra, un cliente ni un logo. En una tanda de quince slides se colaron dos datos creíbles que nadie había dicho. Ningún verificador automático los caza: se revisa la pieza contra su encargo, a mano.