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

Tampoco soy una persona de UI. Bueno, hago UI 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 la parte delantera.

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 pocos desafíos o innovaciones en cómo se puede implementar una interfaz de usuario, y solo hay tantas veces que uno puede poner una casilla de verificación en la pantalla antes de volverse un poco mental. Y eso ni siquiera se refiere a pasar horas alineando píxeles "solo".

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

Los requisitos de back-end generalmente se pueden especificar como una caja negra, x entra y se espera que y salga. Hacer que funcione involucra la implementación de la lógica y usted puede probar programáticamente si funciona o no.

Para hacer una buena interfaz de usuario, debe considerar la usabilidad, el diseño visual, el diseño y cosas como los esquemas de color. Tener algo de creatividad artística es una ventaja aquí, y muchos programadores no sienten que tengan esto. Para un cerebro lógico, la solución a un problema de la interfaz de usuario puede parecer subjetiva, ya que no hay una respuesta correcta o una forma sencilla de validar que se ha hecho "correctamente".

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

Por supuesto, algunos programadores no tienen un problema con este aspecto, pero lo odian porque muchas interfaces de usuario son simplemente aburridas de codificar. Pueden consistir en mucho trabajo repetitivo, como páginas de formularios para páginas de administración, en las que solo necesitan ser funcionales y no hay ningún desafío de diseño.

La gente tiene 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 interfaz de usuario, o cualquier combinación de estos y otros nichos. Cada uno requiere diferentes habilidades y diferentes formas de pensar acerca de un problema. Si te gustan las tuercas y los pernos de programación de bajo nivel, tal vez no te importe mucho 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 cosa que me parece interesante.

Si un diseño de UI dado es bueno o malo es bastante subjetivo , lo que creo que los programadores en general encuentran poco atractivo. Unas pocas décadas de esfuerzo para cuantificar y calificar buenas técnicas de UI han ayudado a crear algunas reglas generales que se pueden aplicar, pero la mayoría de las veces para determinar realmente si una UI es buena requiere muchas pruebas A / B y otras observaciones del usuario tecnicas

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

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

No necesariamente creo que algún programador odie diseñar IU 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 IU.

El problema con el diseño de IU es que todos tienen una opinión ... Y no hay una respuesta correcta o incorrecta. Los desarrolladores, por otra parte, aman a Black & Blanco y lógica. En cualquier empresa del tamaño, todos estarán de acuerdo en que 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 trabajar en UI (específicamente, he hecho mi parte del diseño web), aprecio que alguien que no tenga el conjunto de habilidades se quede fuera de él.

El desarrollo requiere la capacidad de tener muchos datos en tu mente y lidiar con muchos a la vez. El diseño de la interfaz de usuario requiere la capacidad de reducirlo lo menos posible, sin sacrificar su integridad. Me amo el desafío de eso; y me estremezco cuando veo a alguien crear 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 otra parte, odio las cosas de bajo nivel. Nunca tocaré el código para los controladores, los núcleos o cualquier otra cosa así: estremecimiento: se lo dejo a los "tipos que no pertenecen a UI", y estoy feliz de que a alguien más le guste hacerlo, o nunca lo haría.

Creo que depende de que la mayoría de los programadores usen 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 recibes demasiados comentarios de las personas equivocadas. Todos ellos son expertos en diseño gráfico. No hay dónde encontrarlos cuando quieres saber la fórmula para 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 las 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" todos y tenerlos en pestañas separadas es demasiado esfuerzo. Ya sabes, lo mismo que Excel. ¡Campesinos!

No puedes hacer esto. Me senté en una reunión donde las dos principales personas del departamento de contabilidad (aproximadamente 500 K / año de sueldo) de una gran firma de abogados pasaron media hora discutiendo sobre una etiqueta en una página web de facturación utilizada por los abogados. Esto se suponía para facilitar la comprensión de los abogados. ¿Por qué no 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 neta residual" de WTF y por qué está en su formulario de registro de tiempo.

A algunas personas les gusta el brócoli, otras no. Puede que tengamos que comerlo, pero no nos tiene que gustar y no lo vamos a disfrutar cuando lo comamos. No solo eso, vamos a evitar tener que comerlo todo lo que podamos.

Hay muchas otras cosas para codificar que solo la interfaz de usuario. Servicios web, servicios de Windows, integrados (no mucho de una interfaz de usuario en un microondas), solo para mencionar algunos ejemplos.

Esto podría deberse a que, en algunos casos, las herramientas que están concebidas expresamente para ayudarlo a dibujar la IU succionan a los monos bebés muertos a través de una pajita.

Hay ciertas cosas en el desarrollo de IU que son difíciles de entender.

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 tareas exigidas por los marcos, diría que la mayoría de las IU complejas tienen problemas de enrutamiento de eventos, que pueden descubrirse si cualquiera de los marcos de prueba podría abordarlos bien.

Sé que para mí solía odiar a los desarrolladores de IU porque me resultaba muy tedioso y lento, especialmente al escribir código de diseño para colocar las cosas en una forma o en una ventana. Ahora, con las herramientas del diseñador de UI, como el Diseñador de formularios en Visual Studio, casi lo disfruto . Otras razones para odiarlo he escuchado de otras personas que 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 creas que deberíamos.

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 lo he mejorado en los últimos años. Sé que algunos desarrolladores no deberían estar autorizados cerca de una hoja de estilo o de una paleta de colores. Definitivamente es un conjunto de habilidades diferente, y no todos lo tienen.

No odio tanto el trabajo de UI como odio algunos marcos de UI. P.ej. He estado programando .NET para > 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).

En este sentido, escribir aplicaciones GUI es más un aspecto del uso de marcos 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 vuelven realmente aburridas.

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

Muchas veces, 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 por ejemplo, cómo obtenemos cambios de un cliente para actualizar de inmediato en otro cliente.

No soy un gran fanático del desarrollo de IU por estas razones:

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

2. La interfaz de usuario es más desordenada, mientras que el extremo posterior es más "platónico". Si bien he visto feos problemas con el código de back-end, 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 IU puede tener un aspecto realmente limpio y estar bien diseñada para el usuario, pero como soy un desarrollador y paso más tiempo en el código que en su uso, me gusta más el código limpio.

3. Siento que la IU es más una "tubería" que el back-end, es decir, hay menos oportunidades para los algoritmos inteligentes y realmente lleva tu cerebro al límite.

Realizo IU (escritorio, no web) y tripas internas.

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

En el dominio de la interfaz de usuario, lo que les presento 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 eventos. manejadores, MVC, todas esas cosas de "estado del arte". Afortunadamente, hace décadas descubrí lo que creo que es una mejor manera, que es hacer un DSL para eso, y trabajar en eso. Actualmente lo llamo Dynamic Dialogs, 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 haya intentado enseñarlo, no he tenido mucha suerte al transferir 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 posteriormente se injertó una interfaz de usuario. Eso le da al usuario experto algo donde puede pasar por alto la interfaz de usuario, mientras que le da al usuario casual algo que puede usar de manera casual. (Ejemplos: R, SPlus, Matlab, SAS, WinBugs). Así que nuestro producto tiene un lenguaje de línea de comandos para expertos Me encanta desarrollar este tipo de cosas, con un analizador, un generador de código, un precompilador y un motor de modelado en tiempo de ejecución. El esfuerzo invertido en eso es al menos una potencia de 10 menos que el esfuerzo invertido en la interfaz de usuario.

Una de las razones por las que el esfuerzo de UI es tanto es que todavía hay mucho "pegamento" que no se puede hacer con un DSL: administrar las cuadrículas de datos, todo tipo de formas de clasificación de datos, todo lo que cae en el bostezo. "crack" entre la interfaz de usuario pura y el lenguaje subyacente.

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

Sinceramente, me parece que encontrar el mejor kit de herramientas de GUI para luego aprender los entresijos de eso es un poco como un PITA ... sin mencionar que no aprendes muchas cosas de UI en la universidad y soy un novato, así que ... ..ya ..

Más allá de lo que ya se ha dicho (es tedioso, aburrido, frustrante trabajar con el código y el diseño generalmente lo hace alguien que no tiene idea de los problemas que causan sus ideas para quienes intentan implementarlas), un factor importante es que tienes que trabajar con personas cuyas ideas sobre lo que deberías hacer cambiando constantemente, mucho más que lo que 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 punteras. Literalmente, las pruebas de error de las interfaces de usuario se deben a que un componente estaba a 1 píxel de la ubicación que la persona que probó pensó que debería haber sido. ¿Funcionó? Sí. ¿Se veía bien? Sí. Pero comenzó a contar píxeles y algo era un solo píxel fuera de línea con el resto, por lo que lo envió de vuelta para volver a trabajar.

Algunos puntos más:

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

2) Muchos programadores no están entrenados en esto, y no saben mucho al respecto.

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

Como estudiante de CS, se te enseñará la estructura de datos, la base de datos, C ++ ... excepto UI. Así que no eres 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 backend, encontré 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 vienen todo el tiempo y ahora, en la era en la que todos los servicios giran en torno a CRUD, se vuelve aburrido.

De todos modos, codificar el frontend permite una mejor interacción y dinámicos locos que básicamente atornillan a una mano sin experiencia en el diseño de frontend. Personalmente aprendí de la manera difícil en la interfaz y puedo decir con comodidad que el diseño de la interfaz es mucho más interesante y desafiante.