Notas de versión para apps móviles: qué recorta el límite

Todo en este hub sobre escribir notas de versión asume una página que se controla por completo: cualquier longitud, enlaces que funcionan, formato que se renderiza. Las notas de versión de una app móvil viven dentro de la caja de otra empresa. Apple da alrededor de 4.000 caracteres pero solo muestra las primeras líneas antes de que se toque “más”; Google da un espacio similar con el mismo problema efectivo de vista previa, y ninguna de las dos plataformas renderiza un enlace clicable dentro del texto. Las reglas de cómo escribir notas de versión que la gente realmente lee siguen aplicando: decir qué cambió y qué tiene que hacer quien lee, pero el espacio para hacerlo es una fracción de lo que permite una página de changelog, y los recortes tienen que ser deliberados, no accidentales.

¿Qué cabe realmente en la vista previa visible?

La primera línea o dos, entre unos 80 y 170 caracteres según el dispositivo y el tamaño de fuente, antes de que quien lee tenga que tocar para expandir. Ese es todo el presupuesto para la parte de la nota de versión que decide si alguien va a leer el resto, y significa que la frase más importante tiene que ir primero, no el número de versión, ni un saludo, ni un encabezado de categoría. Una nota de versión que empieza con “Novedades de esta versión:” ya gastó un tercio de su espacio visible en cuatro palabras que no le dicen nada a quien lee.

¿La regla de “qué puedes hacer ahora, qué se te debe” sigue funcionando a esta longitud?

Sí, y se vuelve más estricta, no distinta. Una frase por entrada, verbo primero, sin introducción: “Exporta tus datos como CSV desde Ajustes.” le gana a “Hemos añadido la capacidad de que ahora los usuarios puedan exportar sus datos en formato CSV” usando un tercio de las palabras para decir lo mismo. A la longitud de una página de changelog, una frase algo verborrágica le cuesta a quien lee medio segundo. A la longitud de una nota de versión móvil, esa misma verborragia puede empujar la frase entera fuera de la vista previa visible, así que quien lee nunca ve el verbo que le habría dicho qué cambió.

Malo, gasta la vista previa en el marco:
"¡Estamos emocionados de traerte una nueva actualización
llena de mejoras! Sigue leyendo para más detalles."

Bueno, todo el valor en la primera línea:
"Exporta tus datos como CSV. El modo oscuro ahora respeta
la configuración del sistema. Se corrigió un fallo al abrir
enlaces compartidos."

¿Qué hay que recortar que una entrada de changelog web normalmente conservaría?

Los enlaces, primero, porque ninguna de las dos tiendas los renderiza como clicables, así que una URL en el texto es peso muerto que quien lee tendría que retipear. Si la entrada necesita un destino, di qué tocar dentro de la app en su lugar: “Ve los nuevos filtros en Ajustes > Búsqueda” funciona; “Lee más en example.com/blog/filtros” no funciona en esta superficie. Segundo, cualquier cosa condicional o específica de un público: un changelog web puede decir “si usas la API, esto te afecta”, pero un listado de tienda llega a cada usuario instalado a la vez, así que una línea condicional se lee como ruido para el 95 % al que no le aplica. Pon el detalle condicional en un mensaje dentro de la app en su lugar, activado para las cuentas a las que realmente concierne.

¿Cada lanzamiento debería tener sus propias notas, o está bien reutilizar “correcciones de errores y mejoras de rendimiento”?

Reutilízalo para lanzamientos que genuinamente sean eso, pero audita cuán a menudo es realmente cierto. Cómo escribir notas de versión ya cubre por qué esa frase delata una nota escrita desde adentro en vez de para quien lee; en móvil hace un daño doble, porque las notas de versión de la tienda son uno de los pocos lugares donde algunos usuarios ven algo entre actualizaciones, y una larga racha de “correcciones de errores y mejoras de rendimiento” se lee como si la app no cambiara, lo cual es una impresión peor que no tener notas en absoluto durante ese tramo.

¿Las notas de versión afectan si la gente actualiza la app?

Indirectamente, a través de la visibilidad más que de la persuasión. La mayoría de los usuarios actualiza automáticamente y nunca lee las notas antes de actualizar; las notas importan más para la minoría que revisa las actualizaciones manualmente, y para quienes reseñan o hacen prensa y repasan el historial de un listado de tienda. Escribir para ese público más pequeño igual vale la pena, porque un listado con un historial real de entradas específicas y fechadas se lee como una app mantenida activamente, y un listado con un año de “correcciones de errores y mejoras de rendimiento” no, sin importar cuánto se haya lanzado en realidad en ese tiempo.

¿Y una actualización forzada, donde la nota tiene que explicar por qué el usuario no tiene opción?

Indica la razón y el plazo en la primera línea, antes que nada, porque una actualización forzada es el único caso en que quien lee ya está molesta antes de empezar a leer. “Esta actualización es necesaria para seguir sincronizando tus datos. Actualiza antes del [fecha] para evitar interrupciones.” dice qué hacer y por qué en una sola frase; enterrar esa razón bajo tres líneas de notas de funciones sin relación se lee como si la app estuviera escondiendo la parte incómoda.

FAQ

¿Las notas de versión móviles deberían coincidir con el changelog web del mismo lanzamiento? Cubrir los mismos cambios subyacentes, pero no palabra por palabra. El changelog web puede permitirse la explicación completa; la nota móvil necesita esos mismos hechos comprimidos en una frase con el verbo primero, lo que normalmente significa que es una reescritura, no una copia.

¿Vale la pena localizar las notas de versión móviles para cada idioma soportado? Sí, más que para un changelog web, porque el listado de la tienda suele ser la única superficie localizada que algunos usuarios ven entre sesiones, y ambas plataformas soportan notas de versión por idioma sin trabajo de ingeniería adicional más allá de la traducción en sí.

¿Qué tan larga debería ser una nota de versión móvil si no hay un límite que obligue a la brevedad? Corta de todos modos. El techo de 4.000 caracteres de iOS rara vez es la restricción real; lo es la vista previa de 2-3 líneas, y escribir más allá de lo que muestra esa vista previa solo significa que menos gente lee la parte que importaba.

¿Las notas de versión necesitan el número de versión en el texto visible? No. La tienda ya muestra el número de versión junto a las notas. Repetirlo dentro del texto gasta caracteres visibles en información que quien lee ya tiene delante.

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente. Si algo está mal, avísanos y lo corregiremos.

Relacionado en changeloop: Plantilla de release notes, Ejemplos de changelog