¿Por qué algunos programadores odian la parte UI del desarrollo? [cerrado]

Muchos programadores que he conocido siempre dicen que "Él no es un tipo de interfaz de usuario". El hecho es que el desarrollo hoy en día, ya sea web, Windows, Linux, OSX o cualquier otro tipo de desarrollo, ahora comprende software con una interfaz de usuario atractiva. ¿Por qué a tantos desarrolladores parece no gustarles el trabajo de IU?

Tampoco soy una persona de UI. Bueno, hago IU en mis propios proyectos, pero en el trabajo no tengo nada que ver con eso: mi trabajo está en las entrañas de la aplicación, no en el front-end.

Más allá de eso, creo que es más aburrimiento que odio. Diseñar la interfaz de usuario es la parte difícil y desafiante. La implementación es principalmente un trabajo duro. Hay muy poco desafío o innovación en cómo se puede implementar una interfaz de usuario, y solo hay tantas veces que se puede poner una casilla de verificación en la pantalla antes de volverse un poco mental. Y eso ni siquiera toca tocar pasar horas alineando píxeles "solo así".

Hacer una buena interfaz de usuario implica muchas habilidades diferentes que escribir un código de back-end.

Los requisitos de back-end generalmente se pueden especificar como un cuadro negro, x entra y se espera que y salga. Hacer que funcione implica implementar la lógica y puede probar mediante programación si funciona o no.

Para hacer una buena interfaz de usuario, debe tener en cuenta la usabilidad, el diseño visual, el diseño y cosas como los esquemas de color. Tener un poco de creatividad artística es una ventaja aquí, y muchos programadores no sienten que lo tengan. Para un cerebro lógico, la solución a un problema de IU puede parecer subjetiva, ya que no hay una respuesta correcta o no hay una manera fácil de validar que se hace 'correctamente'.

Creo que muchos programadores que no tienen mucha experiencia en la interfaz de usuario o no han investigado mucho al respecto no se dan cuenta de que hay reglas y ciencia detrás del buen diseño de la interfaz de usuario tanto desde una perspectiva de usabilidad como de diseño (por ejemplo, color teoría).

Por supuesto, algunos programadores no tienen un problema con este aspecto, pero lo odian porque muchas IU simplemente son aburridas para el código. Pueden consistir en una gran cantidad de trabajo repetitivo, como páginas de formularios para páginas de administración donde solo necesitan ser funcionales y no existe un desafío de diseño.

Las personas simplemente tienen intereses diferentes. Algunos programadores están más interesados ​​en estructuras de datos y algoritmos, algunos en arquitectura, algunos en usabilidad y diseño de UI, o cualquier combinación de esos y otros nichos. Cada uno requiere diferentes habilidades y diferentes formas de pensar sobre un problema. Si le gustan los detalles básicos de la programación, tal vez no le importe tanto cómo piensa el usuario, o viceversa.

Personalmente, caigo en el último campo: prefiero diseñar una interfaz de usuario que un algoritmo complejo. Es justo el tipo de cosas que me parecen interesantes.

Si un diseño de interfaz de usuario dado es bueno o malo es bastante subjetivo , lo que creo que los programadores en general consideran poco atractivo. Unas décadas de esfuerzo para cuantificar y calificar buenas técnicas de interfaz de usuario han ayudado a crear algunas reglas amplias que uno puede aplicar, pero la mayoría de las veces para determinar realmente si una interfaz de usuario es buena requiere muchas pruebas A / B y otra observación del usuario técnicas

Si bien ciertamente hay subjetividad en la programación, comúnmente puede señalar alguna forma de razones objetivas de por qué una opción es mejor que otra: velocidad de ejecución, requisitos de memoria, flexibilidad para satisfacer las posibles necesidades futuras, prácticas que han demostrado ser más efectivas. el pasado, etc. Defender una elección de UI dada, y por lo tanto, incluso hacer la elección en sí misma, generalmente se degrada a "Me gusta", que es un argumento completamente diferente para apoyar.

Personalmente, no disfruto el desarrollo de UI porque no soy bueno en eso. Hay un ENORME elemento de la psicología del usuario que simplemente no soy bueno para entender. Creo que mi mayor problema es que no puedo ponerme en el lugar del usuario. No sé cómo hacer diseños intuitivos en gran medida porque no sé qué es intuitivo para el usuario, ni sé cómo hacer que las cosas se vean bonitas.

No creo necesariamente que algún programador odie diseñar interfaces de usuario tanto como odian hacer cosas en las que no son buenos. Simplemente sucede que hay muchos desarrolladores que no son buenos en el desarrollo de UI.

El problema con el diseño de la interfaz de usuario es que todos tienen una opinión ... Y no hay una respuesta correcta o incorrecta. Los desarrolladores, por otro lado, aman el blanco y negro y la lógica. En empresas de cualquier tamaño, todos estarán de acuerdo 1+1=2, pero pregunte qué fuente hace que sea más fácil de leer (Comic Sans Obviously)... prepárese para la inundación. Diez mil respuestas diferentes y todos tienen razón, porque todos son diferentes.

Como desarrollador que realmente disfruta trabajando en la interfaz de usuario (específicamente, he hecho mi parte del diseño web), aprecio cuando alguien que no tiene el conjunto de habilidades se mantiene al margen.

El desarrollo requiere la capacidad de retener una gran cantidad de datos en su mente, y manejar muchos de una vez. El diseño de la interfaz de usuario requiere la capacidad de reducirlo al mínimo posible, sin sacrificar su integridad. Me encanta el desafío de eso; y me estremezco cuando veo que alguien crea una interfaz de usuario que es un wall-o-data inmanejable en la pantalla. (También soy un geek total cuando se trata de diseño, teoría del color, etc.)

Por otro lado, odio las cosas de bajo nivel. Nunca tocaré el código de los controladores, los núcleos o cualquier otra cosa como esa: estremecimiento: se lo dejaré a los "chicos sin interfaz de usuario", y estoy feliz de que alguien más disfrute hacerlo, o de lo contrario nunca se haría.

Creo que depende de que la mayoría de los programadores usen la parte izquierda de su cerebro.

Una buena fuente para leer más sobre este tema.

El desarrollo de la interfaz de usuario se vuelve complejo porque recibe demasiada información de las personas equivocadas. Todos son expertos en diseño gráfico. No hay dónde encontrarlos cuando quieres saber la fórmula de algo.

No saben lo que quieren, pero lo saben cuando lo ven, no tienen gusto, y aquellos con el poder de decisión no usarán la aplicación de todos modos, pero están seguros de que debería ser verde. Sigue pautas para una buena interfaz de usuario, como limitar la cantidad de campos en un formulario y recibe una solicitud para agregar 50 campos más porque 'los necesitan' a todos y tenerlos en pestañas separadas es demasiado esfuerzo. Ya sabes, lo mismo que Excel. Campesinos!

No puedes inventar esto. Me senté en una reunión donde las dos personas principales en el departamento de contabilidad (aproximadamente 500,000 / año de salario) para un gran bufete de abogados pasaron media hora discutiendo sobre una etiqueta en una página web de facturación utilizada por los abogados. Se suponía que esto facilitaría la comprensión de los abogados. ¿Por qué no solo preguntar a los abogados? Demasiado fácil. Por lo tanto, el departamento de TI recibe 50 llamadas telefónicas de abogados que desean saber el "monto de facturación neto residual" de WTF y por qué está en su formulario de ingreso de tiempo.

A algunas personas les gusta el brócoli, a otras no. Es posible que tengamos que comerlo, pero no tenemos que gustarnos y no lo disfrutaremos cuando lo comamos. No solo eso, vamos a evitar tener que comerlo tanto como podamos.

Hay MUCHAS otras cosas para codificar además de la interfaz de usuario. Servicios web, servicios de Windows, integrados (no una gran interfaz de usuario en un microondas), solo por nombrar algunos ejemplos.

Eso podría deberse a que, en algunos casos, las herramientas que están expresamente concebidas para ayudarlo a dibujar la interfaz de usuario chupan monos bebés muertos a través de una pajita.

Hay ciertas cosas en el desarrollo de UI que son difíciles de corregir.

El diseño es uno de ellos. He estado creando interfaces de usuario durante más de 15 años y todavía no tengo una solución decente para la gestión del diseño.

Otro es el enrutamiento de eventos: incluso con las arquitecturas MVP y las cosas ordenadas por los marcos, diría que las UI más complejas tienen problemas de enrutamiento de eventos, lo que podría descubrirse si alguno de los marcos de prueba podría abordarlos bien.

Sé que para mí solía odiar el desarrollo de la interfaz de usuario porque me pareció muy tedioso y lento, especialmente escribir código de diseño para posicionar las cosas de una forma o winow. Ahora, con herramientas de diseño de UI como Forms Designer en Visual Studio, casi lo disfruto . Otras razones para odiarlo que he escuchado de otros incluyen "es estúpido", "siempre cambia demasiado", "no es lo suficientemente desafiante", "es tedioso / aburrido".

¿Por qué a todos los jugadores de ajedrez no les gusta diseñar tableros de ajedrez y las piezas con las que juegan?

No es extraño que a algunas personas no les guste eso ... es raro que esperes que debamos.

Me gusta trabajar en la interfaz de usuario. Eso no siempre fue cierto para mí, pero mi disfrute del trabajo de UI ha aumentado a medida que he mejorado en los últimos años. Sé que a algunos desarrolladores no se les debe permitir cerca de una hoja de estilo o una paleta de colores. Definitivamente es un conjunto de habilidades diferente, y no todos lo tienen.

No odio tanto el trabajo de interfaz de usuario como odio algunos marcos de interfaz de usuario. Por ejemplo, he estado programando .NET por más de 10 años. Los marcos para crear aplicaciones web son excelentes (ASP.NET WebForms y ASP.NET MVC). Pero los marcos para escribir aplicaciones de escritorio, bueno, no me gustan (WinForms y WPF).

Entonces, a este respecto, escribir aplicaciones GUI es más un aspecto del uso de frameworks que no me gustan.

Hay otro aspecto A menudo trabajo con aplicaciones de estilo "empresarial", es decir, aplicaciones donde una aplicación de escritorio necesita recibir datos de un servidor. En este caso, hay tantas capas de conversión de datos de un formato a otro que se vuelve realmente aburrido.

Por ejemplo, la aplicación recibe información a través de una serie de objetos DTO. La aplicación crea su propio modelo de representación de los datos (no reutiliza las mismas clases de dominio que se crearon en el servidor). Las clases de modelo son consumidas por un modelo de vista (en un patrón MVPM de WPF), que expone las propiedades en el modelo.

Esas son muchas veces que los mismos datos están representados por diferentes clases. Y eso se vuelve aburrido. Pero este es un problema específico de este tipo de aplicación de escritorio.

También hay desafíos interesantes en este tipo de aplicación, como cómo obtenemos cambios de un cliente para actualizarlos inmediatamente en otro cliente.

No soy un gran admirador del desarrollo de UI por estos motivos:

1. Como desarrollador, tiene menos libertad para crear: el cliente puede ver y opinar sobre cada pequeña faceta de la interfaz de usuario, a la que debe reaccionar. Recibirá solicitudes como: cambiar el color de esto; mueve ese botón allí; no importa, muévelo hacia atrás. El código de fondo rara vez es tan visible.

2. La interfaz de usuario es más desordenada, mientras que el back-end es más "platónico". Si bien he visto feos desorden de código de fondo, creo que es más común que esté limpio (desde la perspectiva del código) que el código de la interfaz de usuario. Una interfaz de usuario puede tener un aspecto realmente limpio y estar bien diseñada para el usuario, pero como soy desarrollador y paso más tiempo en el código que en usarlo, me gusta mucho limpiar el código.

3. Siento que la interfaz de usuario es más una "plomería" que el back-end, es decir, hay menos oportunidades para algoritmos inteligentes y realmente llevar tu cerebro al límite.

Hago tanto la interfaz de usuario (escritorio, no web) como las tripas internas.

La cantidad que me gusta o no me gusta depende de cuánto puedo hacer usando algo como un lenguaje específico de dominio (DSL).

En el dominio de UI, lo que estoy presentando a los usuarios y la complejidad de la información que obtengo de ellos es tal que me volvería loco si tuviera que usar herramientas típicas, como diseñadores de formularios, muchos controladores de eventos, MVC , todas esas cosas de "estado del arte". Afortunadamente, hace décadas descubrí que creo que es una mejor manera, que es hacer un DSL para ello, y trabajar en eso. Actualmente lo llamo cuadros de diálogo dinámicos, y se basa en una estructura de control que llamo ejecución diferencial . La buena noticia es que, para una funcionalidad dada, el código fuente es aproximadamente un orden de magnitud menor, lo que me permite poner mucha más funcionalidad en la interfaz de usuario. La mala noticia es que, por mucho que he tratado de enseñarlo, no he tenido mucha suerte transfiriendo la tecnología.

En el dominio sin interfaz de usuario, tomé una lección de una serie de productos que comenzaron como DSL utilizables desde la línea de comandos, en la que luego se injertó una interfaz de usuario. Eso le da al usuario experto algo donde puede pasar por alto la interfaz de usuario, al tiempo que le da al usuario ocasional algo que puede usar de manera informal. (Ejemplos: R, SPlus, Matlab, SAS, WinBugs). Por lo tanto, nuestro producto tiene un lenguaje de línea de comandos para expertos. Me encanta desarrollar tales cosas, con un analizador, generador de código, precompilador y motor de modelado en tiempo de ejecución. El esfuerzo gastado en eso es al menos una potencia de 10 menos que el esfuerzo gastado en la interfaz de usuario.

Una razón por la cual el esfuerzo de la interfaz de usuario es tan grande es que todavía hay mucho "pegamento" que no se puede hacer con un DSL: administrar cuadrículas de datos, todo tipo de formas de clasificar datos, todo lo que cae en la "grieta" bostezante entre la IU pura y el lenguaje subyacente.

Entonces su pregunta fue "¿Por qué algunos programadores odian la parte de desarrollo de la interfaz de usuario?". Solo lo odio por ese "pegamento" para el que no tengo un DSL.

Honestamente, encuentro que encontrar el mejor kit de herramientas de la GUI y luego aprender los entresijos de eso es un poco PITA ... sin mencionar que no aprendes mucho sobre la interfaz de usuario en la universidad y soy un novato, así que ... ya ..

Más allá de lo que ya se ha dicho (es un trabajo tedioso, aburrido y frustrante codificarlo y el diseño generalmente lo hace alguien que no tiene idea de qué problemas causan sus ideas para quienes intentan implementarlas), un factor importante es que usted tienes que trabajar con personas cuyas ideas sobre lo que deberías hacer cambian constantemente, mucho más de lo que lo hacen para el backend. Como resultado, estás disparando contra una especificación en movimiento aún más, y estas personas también tienden a ser quisquillosas. Literalmente, hice que las interfaces de usuario fallaran las pruebas porque un componente estaba a 1 píxel de la ubicación que la persona que lo probaba pensó que debería haber sido. ¿Funcionó? Si. ¿Se veía bien? Si. Pero comenzó a contar píxeles y algo estaba un solo píxel fuera de línea con el resto, por lo que lo envió de nuevo para su revisión.

Algunos puntos más:

1) El diseño de la interfaz de usuario puede ser más difícil de probar, asegúrese de que puede verificar si ese botón hace lo que debería, pero probar si es fácil de usar es más difícil. ¿Qué hay de probar si será utilizable con alguien con discapacidad?

2) Muchos programadores no están capacitados en ello y no saben mucho al respecto.

El hecho es que muchas herramientas UI / framework / API son malas, complejas, muy lejanas para ser intuitivas. Desarrollé con Win32 API en C / C ++, con javax.swing, CSS, etc. Desde entonces, odio tener que lidiar con el desarrollo de UI ... ¡Hasta el marco Qt!

Como estudiante de CS, se le enseñará la estructura de datos, la base de datos, C ++ ... excepto la interfaz de usuario. Entonces no serás bueno desde el principio . Si no eres bueno en eso, lo odiarás.

Después de haber trabajado en ambos lados de la moneda, es decir, el diseño de la interfaz de usuario y el código de back-end, descubrí que ambos lados de la moneda son básicamente lo mismo.

Los requisitos que difieren de lo que haces día a día no llegan todo el tiempo y ahora en la era donde todos los servicios giran en torno a CRUD, se vuelve aburrido.

De todos modos, la codificación de la interfaz permite una mejor interacción y dinamismos locos que básicamente atornillan una mano inexperta en el diseño de la interfaz. Personalmente aprendí el camino difícil en frontend y puedo decir cómodamente que diseñar frontend es mucho más interesante y desafiante.