Cómo reportar errores a Apple usando Feedback assistant

Apple en sus últimas versiones de todos sus sistemas operativos con navegador web incorpora una herramienta para que todos los usuarios puedan notificar de errores o aportar sugerencias. Esta herramienta se llama Feedback assistant.

Para abrir esta herramienta simplemente tenemos que abrir Safari en nuestro Mac o en nuestro iPhone y abrir la siguiente dirección: applefeedback:// 

Nos aparecerá una herramienta para ver el listado de los informes de error enviados y un formulario para enviar nuevos informes de error o sugerencia para cualquier producto Apple.

Cómo notificar de forma apropiada un error en una aplicación o servicio

A la hora de mejorar y mantener un producto software los desarrolladores utilizan el feedback proporcionado por los usuarios a través de lo que se conoce como bug report o feedback report. Un bug report es un mensaje de un usuario al desarrollador indicando que hay un problema en una aplicación.

Este mensaje se puede enviar a través de correo electrónico, mediante una plataforma web de gestión de errores, a través de chat o a través del canal que el desarrollador haya proporcionado para la comunicación con los usuarios.

Un bug report efectivo

En muchas ocasiones los reportes de error enviados por los usuarios son totalmente inútiles y poco efectivos ya que se limitan a mensajes del tipo la app no funciona. Es evidente que si se envía un reporte de error es porque el usuario ha encontrado que algo no funciona pero los desarrolladores, por ahora, no podemos leer el pensamiento de los usuarios por lo que es necesario dar más detalles sobre qué no funciona para encontrar respuesta a la pregunta de por qué no funciona y cómo hace el usuario para que no funcione ya que los desarrolladores antes de publicar sus aplicaciones realizan multitud de pruebas de uso y puede que conocer cómo utilizan su aplicación otras personas les permita mejorar el uso de la misma.

Además, decir que la app no funciona es algo muy general. Una app pequeña tiene entre 4 y 15 pantallas por lo que es de agradecer un poco más de información.

Qué incluir en un reporte de error

A la hora de enviar un reporte de error es muy recomendable incluir los siguientes apartados:

Descripción breve del problema

En un par de párrafos describir qué error sucede. Se recomienda incluir el nombre de la aplicación, en qué pantalla sucede y cómo llegó a esa pantalla.

Paso a paso

Incluir una lista de pasos desde que se abre la aplicación hasta que se obtiene el error o el comportamiento no esperado.

También se debe incluir un paso indicando que se activa el lector de pantallas, el magnificador o cualquier otro producto de apoyo que se esté utilizando ya que a veces los errores sólo suceden con un producto de apoyo.

Además, si el producto de apoyo o la aplicación tiene alguna personalización o ajuste especial que provoque el problema también es necesario indicarlo.

Resultados esperados y resultados obtenidos

Este apartado sirve para indicar qué esperaba el usuario que sucediese y qué es lo que sucede realmente. A veces el problema no es de software sino de lenguaje empleado. El usuario entendió que debería pasar una cosa pero el desarrollador no se explicó bien en el manual o las instrucciones en la aplicación. Este tipo de informes de error permiten solucionar este tipo de problemas de malentendidos o para comprender qué experiencia de uso tienen los usuarios ante ciertas situaciones provocadas por sus aplicaciones.

Los resultados esperados y resultados obtenidos suelen ser un par de párrafos describiendo ambos elementos.

Observaciones

Este apartado suele ser un texto beve donde el usuario puede aportar más información sobre, por ejemplo, si está utilizando el dispositivo con una configuración determinada (por ejemplo un iPhone configurado en Español de USA con modo oscuro y con auriculares), el modelo de su dispositivo o si tenía algún dispositivo más conectado.

Adjuntos al reporte

Adjunto al reporte de errores es recomendable incluir un adjunto con un informe de comportamiento o fichero de log que permita al desarrollador ver el comportamiento interno de la aplicación cuando sucedía el problema.

Si el apartado de paso a paso es muy detallado no es necesario incluir ningún adjunto a menos que el problema lo tenga un usuario en concreto y pueda ser por una configuración muy concreta o un fallo colateral en ese dispositivo concreto. Estos ficheros de log permiten encontrar esa información tan concreta que no es evidente ni para el usuario ni para el desarrollador. 

En la mayoría de ocasiones se piden estos ficheros en una segunda comunicación sólo si el desarrollador no ha podido reproducir el problema reportado por el usuario y tras seguir el paso a paso indicado.

Siempre con educación

Es algo que puede parecer evidente cuando nos comunicamos con otra persona pero es algo que muchas veces se olvida. Si un usuario espera que otra persona atienda a su mensaje con buena disposición es necesario un trato cordial y sin caer en insultos o palabras despectivas hacia la persona que desarrolla el software, su inteligencia o su progenie.

En varias ocasiones he desechado o ignorado reportes de error por estar mal estructurados, no aportar información suficiente o utilizar un lenguaje inapropiado. Y como yo conozco a muchos desarrolladores que hacen lo mismo ya que se considera que ese tipo de feddback no es beneficioso para el software.

Buscando el entendimiento

A veces también hay un problema de comunicación entre el usuario y el desarrollador por el lenguaje empleado. Puede que el usuario no sepa hablar francés y el desarrollador no sepa hablar japonés. En estos casos siempre es recomendable utilizar un idioma neutral, siendo el más común en el desarrollo de software utilizar inglés, y utilizando una herramienta de traducción incluir dentro del texto un aviso indicando que la persona habla en un idioma concreto y que este texto ha sido traducido al inglés gracias a una herramienta de traducción. Esto permite a ambas partes estar atentos a posibles malentendidos a causa de un error en la traducción.

Cómo obtener un informe de comportamiento para el reporte de errores en MacOS

A la hora de notificar errores de software a una compañía o desarrollador es muy importante aportar información sobre qué estaba sucediendo en la máquina cuando se produjo el error

Este informe de comportamiento se puede obtener de forma muy sencilla en MacOS.

Lo primero que debemos hacer es abrir la aplicación Monitor de actividad. Esta aplicación se encuentra en Aplicaciones/Utilidades o también la podemos encontrar fácilmente a través de SpotLight.

Una vez abierta debemos pulsar el botón de menú llamado Acciones que se encuentra dentro de la barra de herramientas. Al pulsar este botón se desplegará un menú. En ese menú debemos seleccionar la opción Diagnóstico del sistema.Al seleccionar esa opción nos aparecerá un diálogo avisando del contrato de privacidad ya que ese informe incorporará información personal sobre el usuario y las aplicaciones en uso. Más concretamente el texto que aparece en el diálogo es el siguiente:

Esta herramienta genera archivos que permiten a Apple investigar sobre problemas con tu ordenador y ayuda a mejorar los productos de Apple.

Estos archivos pueden contener información personal que se haya encontrado en tu dispositivo o que esté relacionada con tus cuentas de iCloud y que incluye, por ejemplo, tu nombre, el número de serie de tu dispositivo, el nombre de tu dispositivo, los dispositivos periféricos que tengas conectados, tu nombre de usuario, tu dirección de correo electrónico, los ajustes de tu cuenta de correo electrónico, nombres y rutas de archivos, las sugerencias de Siri, la dirección IP de tu ordenador e información de la conexión de red.

Apple hace uso de esta información de acuerdo con lo establecido en su política de privacidad (www.apple.com/es/privacy) y no la comparte con ninguna otra empresa.

Al usar esta herramienta y enviar los resultados a Apple, aceptas que Apple utilice el contenido de dichos archivos para mejorar sus productos.

Una vez aceptado el contrato de privacidad comenzará el proceso de generación del informe. Este proceso podrá tardar varios minutos.

Una vez terminada la generación del informe se abrirá Finder en una carpeta donde se almacena información de varios servicios del sistema. En ella deberá haber un fichero comprimido con un nombre parecido a este: sysdiagnose_2023.10.12_07-43-27+0200_macOS_MacBookPro18-4_23A344.tar.gz.

El fichero es pesado (entre 50Mb y 600Mb dependiendo de la actividad en el momento de generarlo) por lo que si se ha de enviar a Apple o a otra compañía será necesario utilizar algún servicio para compartir ficheros pesados.

Este fichero comprimido contiene ficheros logs con información de las aplicaciones que han sido ejecutadas en los últimos días por lo que es importante indicar la hora y minuto en la que sucede el error para que los desarrolladores puedan encontrar el problema.

Controlar errores de ejecución en AppleScript

A la hora de diseñar y codificar nuestros scripts de AppleScript debemos tener en cuenta que se pueden producir errores y debemos controlar lo que sucede cuando aparecen estos errores.

Por defecto en AppleScript cuando sucede un error se para la ejecución del script y, a veces, se da un mensaje de error.

Veamos un ejemplo intentando verbalizar un mensaje con una voz no instalada en el sistema:


say "Hola a todos!" using "Manolo"

Al intentar ejecutar ese código obtendremos el mensaje de error No se ha encontrado la voz.. Debemos controlar esto para que nuestro script siga funcionando perfectamente.

Bloques seguros con try

AppleScript nos permite ejecutar un bloque de código de forma segura utilizando el bloque try. Permitiendo que se ejecute el código pero si aparece un error no se parará la ejecución de nuestro script.

El bloque try utiliza la siguiente sintaxis:


try
-- código a ejecutar de forma segura
end try

Volviendo a nuestro ejemplo anterior ahora podemos evitar que se de el mensaje de error utilizando el bloque try. El código quedaría así:


try
say "Hola a todos!" using "Manolo"
end try

Reaccionando a los errores

A veces nos interesa reaccionar ante la aparición de un error. Por ejemplo, si la voz Manolo no existe, aunque usemos el bloque try tendremos un problema en nuestro script ya que el mensaje nunca llegaá al usuario ya que el mensaje no se verbalizará. La solución pasa por reaccionar al error verbalizando el mensaje de todas formas con cualquier voz que esté disponible. Para ello el bloque try posee la cláusula on error que nos permite definir un sub bloque de código dentro del bloque try que se ejecutará sólo si se produce un error. Su sintaxis es la siguiente:


try
-- Código a ejecutar
on error
-- Código a ejecutar si se produce un error
end try

El código de nuestro ejemplo quedaría así:


try
say "Hola a todos!" using "Manolo"
on error
say "Hola a todos!"
end try

Creando nuestra función

El código necesario para verbalizar un mensaje con una voz en específico de forma segura es candidato a convertirse en una de nuestras funciones habituales. El código podría ser algo como lo siguiente:


on sayWithVoice(texto, nombreDeVoz)
try
say texto using nombreDeVoz
on error
say texto
end try
end sayWithVoice

Para probar nuestra función simplemente debemos llamarla de la siguiente forma:


sayWithVoice("Hola a todos, soy Mónica", "Monica")