Por que alguns programadores odeiam a parte da UI do desenvolvimento? [fechadas]

Eu também não sou uma pessoa de interface do usuário. Bem, eu faço UI em meus próprios projetos, mas no trabalho eu não tenho nada a ver com isso - meu trabalho está no coração do aplicativo, não no front end.

Além disso, acho que é mais tédio do que ódio. Projetar a interface do usuário é a parte difícil e desafiadora. A implementação é principalmente um trabalho pesado. Há muito pouco desafio ou inovação em como se pode implementar uma interface de usuário, e só há tantas vezes que se pode colocar uma caixa de seleção na tela antes de ficar um pouco mental. E isso não é nem tocar em gastar horas alinhando pixels "só isso".

Criar uma boa interface do usuário envolve muitas habilidades diferentes do que escrever um código de back-end.

Os requisitos de back-end geralmente podem ser especificados como uma caixa preta, x entra e é esperado que y saia. Fazer isso funcionar envolve implementar a lógica e você pode testar programaticamente se ela funciona ou não.

Para criar uma boa interface do usuário, você precisa considerar usabilidade, design visual, layout e coisas como esquemas de cores. Ter alguma criatividade artística é um bônus aqui, e muitos programadores não acham que têm isso. Para um cérebro lógico, a solução para um problema de interface do usuário pode parecer subjetiva, já que não há uma resposta correta ou nenhuma maneira fácil de validar que isso seja feito "corretamente".

Acho que muitos programadores que não têm muita experiência em UI ou não fizeram muita pesquisa não percebem que há regras e ciência por trás de um bom design de interface do usuário, tanto da perspectiva da usabilidade quanto do design. (por exemplo, teoria das cores).

Naturalmente, alguns programadores não têm problemas com esse aspecto, mas odeiam isso porque muitas interfaces de usuário são chatas de codificar. Eles podem consistir em um monte de trabalho repetitivo, como páginas de formulários para páginas de administração, onde eles só precisam ser funcionais e não há desafio de design.

As pessoas só têm interesses diferentes. Alguns programadores estão mais interessados em estruturas e algoritmos de dados, alguns na arquitetura, alguns em usabilidade e design de interface do usuário - ou qualquer combinação desses e outros nichos. Cada um deles exige diferentes habilidades e diferentes maneiras de pensar sobre um problema. Se você gosta das porcas e parafusos de programação de baixo nível, talvez não se importe tanto com o modo de pensar do usuário, ou vice-versa.

Pessoalmente, eu caio no último acampamento - prefiro projetar uma interface do usuário do que um algoritmo complexo. É o tipo de coisa que eu acho interessante.

Se um determinado design de interface do usuário é bom ou ruim é bastante subjetivo , o que eu acho que os programadores em geral acham desagradável. Poucas décadas de esforço para quantificar e qualificar boas técnicas de interface do usuário ajudaram a criar algumas regras gerais que podem ser aplicadas, mas na maioria das vezes para determinar se uma UI é boa requer muitos testes A / B e outras observações do usuário técnicas.

Pessoalmente, não gosto de desenvolver a interface porque não sou bom nisso. Há um enorme elemento de psicologia do usuário que eu não sou bom em entender. Eu acho que o meu maior problema é que eu não posso colocar-me no lugar do usuário. Eu não sei como fazer layouts intuitivos em grande parte porque eu não sei o que é intuitivo para o usuário, nem sei como fazer as coisas parecerem bonitas.

Eu não acho necessariamente que algum programador odeie o design de interfaces de usuário tanto quanto eles odeiam fazer coisas que eles não são bons. Acontece que há muitos desenvolvedores que não são bons no desenvolvimento da interface do usuário.

O problema com o design da interface do usuário é todo mundo ter uma opinião ... E não há resposta certa ou errada. Desenvolvedores, por outro lado, amam black & branco e lógica. Em qualquer tamanho de empresa, todos concordarão que 1+1=2 , mas perguntarão qual fonte facilita a leitura de (Comic Sans Obviously) ... prepare-se para a inundação. Dez mil respostas diferentes e todo mundo está certo, porque todo mundo é diferente.

Como um desenvolvedor que realmente gosta de trabalhar na interface do usuário (especificamente, eu fiz o meu quinhão de web design), eu aprecio quando alguém que não tem o conjunto de habilidades fica de fora.

Por outro lado, eu odeio coisas de baixo nível. Eu nunca vou tocar código para drivers, kernels ou qualquer outra coisa parecida: shudder: Eu deixo isso para os "caras que não são da interface do usuário", e estou feliz que alguém mais goste de fazer isso, ou nunca seria feito.

Eu acho que depende da maioria dos programadores usarem a parte esquerda do cérebro deles.

Uma boa fonte para ler mais sobre este assunto.

O desenvolvimento da interface do usuário fica complexo porque você recebe muita informação das pessoas erradas. Eles são todos especialistas em design gráfico. Eles não são onde encontrar quando você quer saber a fórmula de alguma coisa.

Eles não sabem o que querem, mas sabem quando vêem, não têm gosto, e aqueles com poder de decisão não usam o aplicativo, mas têm certeza de que ele deve ser verde. Você segue as diretrizes para uma boa interface do usuário, como limitar a quantidade de campos em um formulário e receber uma solicitação para adicionar mais 50 campos porque eles 'precisam' de todos eles, e tê-los em guias separadas é um esforço demais. Você sabe, o mesmo que o Excel. Camponeses!

Você não pode inventar isso. Sentei-me em uma reunião em que as duas principais pessoas no departamento de contabilidade (aproximadamente 500 mil / ano de salário) de um grande escritório de advocacia gastavam meia hora discutindo sobre um rótulo em uma página do site de faturamento usada pelos advogados. Isso deveria facilitar a compreensão dos advogados. Por que não apenas perguntar aos advogados? Muito fácil. Assim, o departamento de TI chega a receber 50 ligações telefônicas de advogados que querem saber qual é a "Quantia de Cobrança Líquida Residual" da WTF e por que ela está no formulário de registro de horas.

Algumas pessoas gostam de brócolis, outras não. Podemos ter que comê-lo, mas não temos que gostar e não vamos aproveitar quando o comemos. Não só isso, vamos evitar ter que comê-lo tanto quanto pudermos.

Há MUITAS outras coisas para codificar do que apenas a interface do usuário. Serviços da Web, Windows Services, incorporados (não muito de uma interface do usuário em um microondas), apenas para citar alguns exemplos.

Isso pode ser porque - em alguns casos - ferramentas que são expressamente concebidas para ajudá-lo a desenhar a interface do usuário sugam macacos bebês mortos através de um canudo.

Há certas coisas no desenvolvimento da interface do usuário que são difíceis de acertar.

O layout é um deles. Eu tenho construído UIs por mais de 15 anos e ainda não tenho uma solução decente para o gerenciamento de layout.

Outra é o roteamento de eventos - mesmo com arquiteturas MVP e coisas obrigatórias por frameworks, eu diria que as interfaces mais complexas têm problemas de roteamento de eventos - o que pode ser descoberto se alguma das estruturas de teste puder resolvê-los bem.

Eu sei que para mim eu costumava odiar a interface do usuário porque achei muito tedioso e lento, especialmente escrevendo código de layout para posicionar as coisas em um formulário ou winow. Agora, com ferramentas de designer de interface do usuário, como o Designer de formulários no Visual Studio, quase aproveito . Outras razões para odiar que ouvi de outras pessoas incluem "é estúpido", "sempre muda demais", "não é um desafio", "é tedioso / chato".

Não é estranho que algumas pessoas não gostem disso ... é estranho que você espere que devamos.

Eu gosto de trabalhar na interface do usuário. Isso nem sempre foi verdade para mim, mas minha satisfação com o trabalho na UI aumentou à medida que melhorei nos últimos anos. Eu sei que alguns desenvolvedores não devem ser permitidos perto de uma folha de estilo ou de uma paleta de cores. É definitivamente um conjunto diferente de habilidades, e nem todo mundo tem isso.

Eu não tanto odeio trabalho de interface do usuário como eu odeio algumas estruturas de interface do usuário. Por exemplo. Eu tenho programado o .NET para > 10 anos. Os frameworks para criação de aplicações web são ótimos (ASP.NET WebForms e ASP.NET MVC). Mas as estruturas para escrever aplicativos de desktop, bem, eu não gosto deles (WinForms e WPF).

Então, a esse respeito, escrever aplicativos GUI é mais um aspecto do uso de frameworks dos quais não gosto.

Existe outro aspecto. Costumo trabalhar com aplicativos de estilo "corporativo", ou seja, aplicativos nos quais um aplicativo de desktop precisa receber dados de um servidor. Nesse caso, há tantas camadas de conversão de dados de um formato para outro que fica realmente muito chato.

Por exemplo o aplicativo recebe informações por meio de uma série de objetos DTO. Em seguida, o aplicativo cria sua própria representação de modelo dos dados (não reutilizando as mesmas classes de domínio que foram criadas no servidor). As classes de modelo são consumidas por um modelo de visualização (em um padrão MVP do WPF), que expõe as propriedades no modelo.

Muitas vezes, os mesmos dados são representados por classes diferentes. E isso fica chato. Mas este é um problema específico para este tipo de aplicativo de desktop.

Também há desafios interessantes nesse tipo de aplicativo, como a forma de obter alterações de um cliente para atualizar imediatamente em outro cliente.

Não sou muito fã do desenvolvimento da interface do usuário por esses motivos:

1. Como desenvolvedor, você tem menos liberdade para criar: o cliente pode ver e ter opiniões sobre cada pequena faceta da interface do usuário, à qual você precisa reagir. Você receberá solicitações como: altere a cor disso; mova esse botão para lá; Não importa, mova de volta. O código de back-end raramente é tão visível.

2. A interface do usuário é mais confusa, enquanto o back-end é mais "platônico". Embora eu tenha visto bagunças feias de código de back-end, acho que é mais comum estar limpo (de uma perspectiva de código) do que o código da interface do usuário. Uma interface do usuário pode ser realmente limpa e bem projetada para o usuário, mas como sou um desenvolvedor e gasto mais tempo no código do que usá-lo, gosto mais de limpar o código.

3. Eu sinto que a interface do usuário é mais um "encanamento" do que o back-end, ou seja, há menos oportunidades para algoritmos inteligentes e realmente levar o seu cérebro ao limite.

Eu faço tanto interface do usuário (desktop, não web) quanto interna.

A quantidade que eu gosto ou não gosto de um deles depende de quanto eu posso fazer usando algo como uma linguagem específica de domínio (DSL).

No domínio da interface do usuário, o que estou apresentando para os usuários e a complexidade das informações que estou obtendo deles é tal que eu ficaria louco se tivesse que usar ferramentas típicas, como designers de formulários, muitos eventos manipuladores, MVC, tudo o que "estado da arte" coisas. Felizmente, décadas atrás eu descobri o que eu acho que é uma maneira melhor, que é fazer uma DSL e trabalhar nisso. Atualmente eu chamo de Dynamic Dialogs, e é baseado em uma estrutura de controle que eu chamo de Execução Diferencial . A boa notícia é que, para uma determinada funcionalidade, o código-fonte é aproximadamente uma ordem de magnitude menor, o que me permite colocar muito mais funcionalidade na interface do usuário. A má notícia é que, por mais que eu tenha tentado ensinar, não tive muita sorte em transferir a tecnologia.

No domínio não relacionado à IU, aproveitei uma lição de vários produtos que começaram como DSLs utilizáveis na linha de comando, na qual uma IU foi posteriormente enxertada. Isso dá ao usuário especialista algo em que ele pode ignorar a interface do usuário, dando ao usuário casual algo que ele pode usar casualmente. (Exemplos: R, SPlus, Matlab, SAS, WinBugs.) Então nosso produto tem uma linguagem de linha de comando para especialistas. Adoro desenvolver essas coisas, com um analisador, gerador de código, pré-compilador e mecanismo de modelagem em tempo de execução. O esforço gasto nisso é pelo menos uma potência de 10 a menos que o esforço gasto na interface do usuário.

Um motivo pelo qual o esforço da interface do usuário é tanto é que ainda há muita "cola" que não pode ser feita com redes de dados de gerenciamento de DSL, todos os tipos de dados de classificação, todas as coisas que caem no bocejo "crack" entre a interface do usuário pura e a linguagem subjacente.

Então sua pergunta foi "Por que alguns programadores odeiam a parte de desenvolvimento do UI?". Eu só odeio por causa daquela "cola" para a qual eu não tenho DSL.

Além do que já foi dito (é um trabalho entediante, chato e frustrante codificá-lo e o design geralmente é feito por alguém que não tem ideia de quais problemas suas ideias causam para aqueles que tentam implementá-los), um fator importante é que você está tendo que trabalhar com pessoas cujas idéias sobre o que você deveria estar fazendo mudam constantemente, muito mais do que para o backend. Como resultado, você está atirando contra uma especificação em movimento ainda mais, e essas pessoas tendem a ser nitpickers também. Eu literalmente tenho testes de falhas de interfaces de usuário porque um componente tinha 1 pixel de distância do local em que a pessoa que estava testando o produto achava que deveria ter sido. Funcionou? Sim. Pareceu bom? Sim. Mas ele começou a contar os pixels e algo estava com um único pixel fora de linha com o resto, então ele mandou de volta para o retrabalho.

Mais alguns pontos:

1) O design da interface do usuário pode ser mais difícil de testar, com certeza você pode verificar se esse botão faz o que deveria, mas testar se é fácil de usar é mais difícil. Que tal testar se será utilizável com alguém com deficiência?

2) Muitos programadores não são treinados e não sabem muito sobre isso.

O fato é que muitas ferramentas de interface do usuário / framework / API são ruins, complexas, muito longe de serem intuitivas. Desenvolvi com API Win32 em C / C ++, com javax.swing, CSS, etc Desde então, eu odeio tem que lida com o desenvolvimento de UI ... Até o framework Qt!

Como aluno de CS, você aprenderá estrutura de dados, banco de dados, C ++ ... exceto UI. Então você não vai muito bem desde o começo. Se você não é bom nisso, vai odiá-lo.

Tendo trabalhado nos dois lados da moeda, ou seja, no design da interface do usuário e no código de backend, descobri que os dois lados da moeda são basicamente a mesma coisa.

Requisitos que diferem do que você faz no dia a dia não vêm o tempo todo, e agora, na era em que todos os serviços giram em torno do CRUD, isso se torna entediante.

De qualquer forma, codificar o frontend permite uma melhor interação e dinamismos loucos que basicamente estragam uma mão inexperiente no design frontend. Eu pessoalmente aprendi da maneira mais difícil no frontend e posso dizer que o frontend de design é muito mais interessante e desafiador.