¿Apropiado para poner problemas conocidos directamente en el software?

Me hice cargo del mantenimiento de una aplicación de Android, y hay algunos problemas residuales que he solucionado más o menos, pero aún tengo problemas debido a las diferentes versiones del sistema operativo Android.

Por ejemplo, enviar una solicitud web con la clase MediaPlayer tiene encabezados HTTP personalizados eliminados por el sistema operativo antes de enviar la solicitud, pero solo en Android 4.X (lo probé exhaustivamente), y eso hace que esta característica en particular falle porque se basa en esos encabezados.

Este es un problema conocido y estoy tratando de solucionarlo, pero sería una buena idea tener una verificación condicional como

if (OS.VERSION == 4) {
    knownIssueDialog(This feature will not work on your Android version... etc.");
}

Obviamente, tendríamos esto en cuenta en nuestro canal de soporte, pero me pregunto si sería una buena idea (suponiendo que todo esté al tanto) tener estos problemas conocidos también integrados en el software, y presentarlos cuando y donde sea necesario, como lo que describí anteriormente.

Seguimos recibiendo múltiples críticas negativas y muchos correos electrónicos de soporte basados ​​en este tipo de problemas, por lo que, en mi opinión, ahorraría mucho tiempo y dolor de cabeza a todos simplemente bloqueando una función donde se sabe que no funciona correctamente.

Veo dos problemas potenciales:

1. Los usuarios probablemente nunca antes hayan visto algo así como un diálogo de "problema conocido"; muchos usuarios simplemente podrían no entender lo que significa.
2. Hay un poco de sobrecarga en el desarrollo: sería necesario asegurarse de realizar un seguimiento de estos problemas en algún lugar del código. Afortunadamente, con las anotaciones de Java, cualquier verificación condicional como esa podría estar precedida @KnownIssueo algo así, haciendo que encontrarlas / modificarlas sea muy simple.

¿Tendría sentido poner mensajes de "problema conocido" en el software?

Editar : agregaré que este es un problema que comenzó a ocurrir hace aproximadamente una semana. He corregido a medias el problema, y ​​es muy poco probable que pueda solucionarlo para 4.X porque es el sistema operativo el que está causando el problema. Podría lanzar una nueva versión con la solución y hacer feliz al 50% de la base de usuarios nuevamente, y advertir al otro 50% (usuarios de 4.X) que el problema persistirá en 4.X, y sugerir una actualización (o algo así) ) La pregunta es si hacer eso o no en el software (es decir, mostrar un cuadro de diálogo a los usuarios de 4.X), o simplemente dejar que nos envíen correos electrónicos de soporte que dicen "¡su solución no funcionó!" y luego dirígelos a la página de soporte que discute el problema con más detalle.

Sí, esto es muy aceptable para algunas características más oscuras, especialmente cuando están ocultas en el menú de opciones. Quizás sea mejor deshabilitar los botones y agregar texto adicional "esta función en XXX y abajo" o "esta función funciona de manera óptima en XXX y arriba" si solo funciona de manera parcial.

No, esto no es aceptable en una función clave que ocupa el 75% de la pantalla cuando inicia su aplicación. Tus usos se enfadarán cada vez que vean la ventana emergente. Es mejor que solo oculte la función, no es necesario que moleste a sus usuarios sobre algo que no pueden solucionar.

Sería diferente si los usuarios pueden solucionarlo fácilmente, por ejemplo, instalando una aplicación adicional. A menudo he visto mensajes como "Para usar esta opción, debe instalar la aplicación de brújula (gratuita)" o "Para usar esta opción, necesita actualizar a la aplicación profesional de pago", etc.

La conclusión es que puede hacer esto, pero solo después de una cuidadosa consideración y después de que otras soluciones fallen, no como un atajo rápido. Molestará a sus usuarios, pero eso puede ser una compensación aceptable que realice.

(ps. Tengo la sensación de que esta pregunta debería ir a UX )

Múltiples comentarios negativos + toneladas de correos electrónicos de soporte == clientes insatisfechos. ¿Vas a hacerlos felices 'fallando con más gracia' para ciertas condiciones? Tal vez. Sin embargo, si fuera usted, volvería a pensar si lancé el software prematuramente y debería haber solucionado algunos de esos problemas antes de que se presentara al cliente.

Actualización: si este es un problema que no se puede solucionar debido al entorno, pondría el aviso para informar a los usuarios (Y también lo documentaría y lo enviaría por correo electrónico). Esto funciona para un problema aislado como este, pero no lo recomendaría como una solución general para cualquier 'error conocido'. Si hay muchos de estos, entonces estás haciendo algo mal.

Si las características problemáticas están disponibles a través de opciones, botones o algo similar, puede deshabilitar u ocultar estos elementos: espero que esto sea menos frustrante para el usuario que que se le ofrezca una función solo para que le digan "no funciona". Si sabe que no va a funcionar, no lo haga parecer como podría.

• Deshabilitar la opción / botón le permitirá agregar una nota que dice "no es compatible con su sistema operativo".
• Ocultar el botón / opción no confundirá a los nuevos usuarios, pero puede causar quejas de los usuarios existentes que ya no pueden encontrar el artículo.