Redactar para que mole.

(Nota: Este post lo habíamos publicado en el pasado, pero ya no está online. Lo hemos rescatado porque pensamos que aún es útil si planeas mandar un abstract de charla a Commit o cualquier otro evento tecnológico)

¿Te queda claro cómo conectar tu iPhone con la heladera para seleccionar sabor dependiendo de la carta de Magic que se le ponga delante, pero escribir una descripción de esto para contárselo al mundo se te hace cuesta arriba? Enhorabuena: este post es para ti.

Cada año recibimos 500-600 descripciones de charlas, y las evaluamos en base a tres criterios: el contenido de la charla, el perfil del/de la ponente, y las tecnologías que tenemos que cubrir.

Eso nos toma un ratito, pero los asistentes usan un modelo simplificado bastante más eficiente: leen el título y los primeros dos párrafos en diagonal y de corrido. Y eligen en base a eso.

Decidimos escribir este post porque hemos pasado un rato hablando con ponentes tremendos, con unas charlas con muchísimo peso que estaban introduciendo descripciones muy superficiales. Por decirlo en una frase: "yo, que normalmente iría a tu charla de cabeza, con esta descripción seguiría buscando". Y eso es una pena.

El punto de partida

Una nota rápida sobre el objetivo de una descripción de charla:

• El título: por qué vas a entrar a mi charla y no a ninguna de las otras once sesiones simultáneas. Debería estar diseñado para identificar el contenido en veinte segundos.
• La descripción: empezando por el contenido más importante, y decreciendo en intensidad. El contenido menos importante al final.
• Cerrar con un Call to Action o similar.
• Simplificar contenidos. Hemingway y Orwell llamaban a esto to kill your darlings: reescribe el texto siempre que veas una forma más simple de entregar el mismo mensaje.

Típicamente las charlas de las que estamos hablando empiezan con algo así*:

Título: HTML5 y JavaScript en el siglo XXI.

Descripción: Cualquier desarrollador JavaScript sabe en el siglo XXI que nuestras metodologías han cambiado. Los procesos que se podían considerar válidos en los años anteriores ahora han quedado obsoletos y desfasados. En esta charla describimos un modelo más eficiente de desarrollo web basado en los últimos estándares, aplicando nuevas funcionalidades disponibles en los navegadores para dar mejor rendimiento en el cliente.

* un caso totalmente ficticio y no basado en nada real. Si tu charla es así, toca cambiarla :)

Cuál es el problema:

• La ambigüedad: Si escribes para una conferencia técnica, sé concreto/a. Menciona las tecnologías que piensas describir, los patrones que piensas utilizar, los casos de uso, indica claramente lo que se va a aprender.
• Preámbulos: Elimina la introducción, siempre que puedas. Empieza por el contenido más importante, y ve bajando en importancia.
• Simplifica. Ya sabes, be Hemingway my friend.
• Ya para nota, conecta con el que te lee. Haz que se ría, haz que simpatice contigo. No expongas hechos en frío, trata de ser cercano/a.

No es que nosotros sepamos hacerlo bien, pero si tuviésemos esta charla en mente arrancaríamos así:

Título: LocalStorage, IndexedDB y ServiceWorker en el navegador. Ya vale de tenerle miedo a las cosas.

Descripción: Si eres de los que mira el desarrollo web basado en Offline First con mezcla entre recelo y ganas de probar, ésta es tu charla. Compararemos las diferencias de almacenamiento con LocalStorage e IndexedDB, veremos para qué caso es importante cada una y completaremos con un glorioso website que funciona sin conexión a la red, una aplicación nunca vista hasta ahora en Internet:

Haremos una to-do list.

Probablemente tu charla tendrá una descripción algo más larga. Posiblemente no siga esta estructura. Pero la idea es que se parezca más a esto que a lo anterior.

Un par de consejos adicionales:

• Tu charla puede ir dirigida a desarrolladores/as principiantes o avanzados/as. Tu descripción debe ir decididamente hacia uno de estos dos colectivos, y no quedarse a medias.
• El contenido de tu charla, sin embargo, no debería dejar fuera ninguno de estos dos colectivos. Intenta escribir una charla en donde personas principiantes y avanzadas puedan llevarse algo. Deja caer un par de slides con contenido avanzado en una charla de principiantes, pon algo de introducción rápida en una charla avanzada. No dejes uno de estos dos grupos completamente de lado.
• A efectos prácticos puedes considerar a los desarrolladores/as intermedios/as como avanzados/as. Normalmente serán capaces de seguirte.
• Las recomendaciones que has visto aquí pueden aplicarse igualmente para el contenido de tu charla: elimina la introducción, simplifica contenidos, cierra con un Call To Action.
• Sáltate estas recomendaciones cuando no tengan sentido o no te pillen inspirado/a.

Al final, si miras el contenido de tu charla en los zapatos de otra persona y decides que igualmente querrías entrar a verla, probablemente lo estés haciendo bien.

Y recuerda: nuestro Call for Papers está gestionado con Koliseo, que te permite cambiar la descripción de tu charla incluso cuando forme parte de la agenda final. Siempre hay tiempo para simplificar después.

¿Ya has enviado tu charla? ¿O piensas esperar a ver si se escribe sola? Vamos a dejar caer un enlace aquí, por si ayuda: envía tu charla*.

* Sí, ahora ya sabes cómo se llama esto.