¿Por qué la programación de IU consume mucho tiempo, y qué se puede hacer para mitigar esto?

Question

En mi experiencia, la programación de IU consume mucho tiempo, es costosa (diseñadores, gráficos, etc.) y es propensa a errores, y por definición los errores de IU o fallas técnicas son muy visibles.

¿Qué se puede hacer para mitigar este problema?

¿Conoces una solución que pueda convertir automáticamente una API a una interfaz de usuario (preferiblemente una interfaz de usuario web?).

Probablemente algo así como una consola JMX

• con buenos valores por defecto
• puede ser ajustado con CSS
• donde los campos se pueden configurar para ser botón de radio o lista desplegable, campo de texto o área de texto, etc
• localizable
• etc

Answer 1

El desarrollo de la IU consume mucho tiempo y es propenso a errores porque implica design.No solo diseño visual o de sonido, sino más importante diseño de interacción. Una buena API siempre es neutra en el modelo de interacción, lo que significa que impone restricciones mínimas al flujo de trabajo real, la localización y la representación de la información. El principal impulsor detrás de esto es la encapsulación y la reutilización del código.

Como resultado, es imposible extraer suficiente información de API solo para construir una buena interfaz de usuario adaptada a un caso específico de uso de API.

Sin embargo, hay generadores de UI que normalmente producen pantallas CRUD basadas en una API determinada. Huelga decir que tales UI generadas no son muy adecuadas para usuarios frecuentes con demandas de mayor eficiencia de UI, ni son particularmente fáciles de aprender en el caso de un sistema más grande ya que realmente no comunican bien la imagen del sistema o la secuencia de interacción.

Se necesita un gran esfuerzo para crear una buena IU porque debe diseñarse según las necesidades específicas del usuario y no debido a una tarea de conversión de API-UI mundana que puede automatizarse por completo.

Para acelerar el proceso de creación de la IU y mitigar los riesgos, es posible sugerir ya sea que se trate de profesionales de IU o que usted mismo conozca más sobre el trabajo. Desafortunadamente, no hay atajos o varitas mágicas, por así decirlo, se producirá una interfaz de usuario de calidad basada enteramente y solo en una API sin mucha información adicional y análisis.

Consulte también una excelente pregunta: "Why is good UI design so hard for some developers?" que tiene algunas respuestas muy interesantes y valiosos, en concreto:

• Enchufe desvergonzado para my own answer.

• Great answer por Karl Fast.

Answer 2

si ya sabe o podría aprender a usar Ruby on Rails, ActiveScaffold es excelente para esto.

Answer 3

Parece que está buscando el patrón Architectual 'Naked Objects'. Hay varias implementaciones disponibles.

http://en.wikipedia.org/wiki/Naked_objects

Answer 4

no estoy dando una solución, pero voy a intentar responder el porqué.

Así que no hablo por todos, pero al menos para mí, creo que una razón es porque los programadores tienden a concentrarse más en la funcionalidad que en la usabilidad y tienden a no ser muy artísticos. Creo que tienden a tener un tipo diferente de creatividad. Considero que me lleva mucho tiempo crear los gráficos adecuados, en comparación con el tiempo que tardo en escribir el código (aunque, en general, no he realizado ningún proyecto con demasiados requisitos gráficos).

Answer 5

No creo que la programación de IU consuma más tiempo que cualquier otro tipo de programación, ni es más propensa a errores. Sin embargo, los errores en la interfaz de usuario a menudo son más obvios. Descubrir un error en un compilador a menudo es mucho más complicado.

Una diferencia clara entre la programación de IU es que tiene una persona en el otro extremo, en lugar de otro programa, que a menudo es el caso cuando escribe compiladores, analizadores de protocolos, depuradores y otro código que habla otros programas y computadoras. Esto significa que la entidad con la que se está comunicando no está bien especificada y puede comportarse de forma muy errática.

EDITAR: "impredecible" es probablemente un término más apropiado./Jesper

Tu pregunta de convertir una API a una interfaz de usuario simplemente no tiene sentido para mí. ¿De qué estás hablando?

Answer 6

Una razón es que no tenemos un patrón bien desarrollado para UTDD - Desarrollo impulsado por prueba de usuario. Tampoco he visto muchos buenos ejemplos de mapeo de Historias de usuarios a Pruebas unitarias. ¿Por qué, por ejemplo, hay pocos tutoriales que analicen User Stories?

Answer 7

la generación automática de las interfaces de usuario pueden ser posibles en cierta medida, en que puede generar controles para la entrada requerida y salida de datos. Pero el diseño de la interfaz de usuario es mucho más complicado que simplemente poner los controles necesarios en una pantalla. Con el fin de crear una interfaz de usuario utilizable y fácil de usar, se deben combinar los conocimientos de disciplinas como el diseño gráfico, la ergonomía, la psicología, etc. Hay una razón por la cual la interacción humano-computadora se está convirtiendo en una disciplina propia: no es trivial crear una IU decente.

Así que no creo que haya una solución real a su problema. El diseño de la interfaz de usuario es una tarea compleja que simplemente lleva tiempo hacerlo correctamente. La única área donde es relativamente fácil ganar algo de tiempo es con las herramientas: si tiene herramientas poderosas para implementar el diseño de la interfaz de usuario, no tiene que codificar manualmente cada píxel de la IU.

Answer 8

ASP.NET Dynamic Data es algo que debe investigar. Cumple con la mayoría, si no con todos sus requisitos

Answer 9

¡Tiene toda la razón cuando dice que la IU consume mucho tiempo, es costosa y propensa a errores!

un gran compromiso que he encontrado es la siguiente ...

me di cuenta de que una gran cantidad de datos (si no la mayoría) se pueden presentar usando una tabla simple (como un JTable), en lugar de tratar de forma continua para crear paneles personalizados y elegantes GUI's. No parece obvio al principio, pero es bastante decente, utilizable y visualmente atractivo.

¿Por qué es tan rápido?Porque pude crear un marco reutilizable que puede aceptar una colección de modelos concretos y con poco o ningún esfuerzo puede representar todos estos modelos dentro de la tabla. Tanto código de reutilización, es increíble.

Al agregar una barra de herramientas sobre la ventana, mi marco puede agregar, eliminar o editar entradas en la tabla. Utilizando toda la potencia de JTables, puedo ocultar (filtrando) y ordenar según sea necesario ampliando varias clases (pero solo si/cuando esto es obligatorio).

Me encuentro reutilizando una gran cantidad de código cada vez que quiero mostrar y administrar nuevos modelos. Hago un uso extenso de iconos (por columna, filas o celdas, etc.) para embellecer las pantallas. Utilizo iconos grandes como encabezado de ventana para hacer que cada pantalla 'aparezca' diferente y atractiva, y siempre se ve como pantallas nuevas y diferentes, pero siempre tiene el mismo código detrás de ellas.

Se requirió mucho trabajo y esfuerzo al principio para hacer el marco, pero ahora está pagando a lo grande.

Puedo escribir la GUI para una aplicación completamente nueva con hasta 30 a 50 modelos diferentes, que consta de tantas pantallas en una fracción del tiempo que me llevaría usar el 'método de IU personalizado'.

¡Le recomendaría que evalúe y explore este enfoque!

Answer 10

¡Es difícil porque la mayoría de los usuarios/clientes son tontos y no pueden pensar con claridad! :) ¡Lleva mucho tiempo porque los desarrolladores/diseñadores de UI son tan obsesivos-compulsivos! :)