De um modo geral, é melhor criar todas as partes funcionais ou fazer a interface do usuário funcionar primeiro - ou uma mistura das duas?


47

De um modo geral, é melhor criar todas as partes funcionais ou fazer a interface do usuário funcionar primeiro - ou uma mistura das duas?

Supondo que você esteja trabalhando em algo grande, é prática geralmente aceita fazer com que todos os blobs funcionais de coleta de dados funcionem antes de qualquer interface do usuário, faça com que toda a interface do usuário trabalhe uma peça de cada vez, ou algo no meio?

Nós todos sabemos dividir o trabalho em partes gerenciáveis, mas a questão é, em última análise, se a UI é incluída em partes gerenciáveis, suponho.

Para o caso do exemplo, considere um aplicativo GUI com uma janela raiz, mas com mais de uma dúzia de guias em várias estações para separar diferentes componentes de dados. Cada guia individual possui um conjunto relativamente complexo de partes móveis, a partir de uma perspectiva de unidades funcionais.

O aplicativo de exemplo nesta pergunta em particular está aqui com o blog que acompanha e o produto comercial original .

Respostas:


85

Existe uma concepção geral entre muitos usuários e clientes comerciais de que, quando parece completo, está quase completo. Como você provavelmente sabe, isso está longe da verdade. Pode-se ter uma boa aparência, mas sem back-end e alguns usuários pensam que fazer com que pareça agradável é 80% do trabalho, não 20% ( ou os outros 80% ).

Inúmeros desenvolvedores podem contar histórias de horror sobre isso - obter uma maquete das páginas feitas no Microsoft Word usando capturas de tela de alguma outra ferramenta, e o cliente dizendo "então, você quase conseguiu?"

Você precisa acompanhá-lo para que todas as peças estejam prontas quando terminar. Tentar fazer todo o back-end primeiro e depois todo o front-end levará o usuário final a pensar que você não está fazendo nada e a perguntar por que você está sendo pago quando não há nada para mostrar. Por outro lado, primeiro o front end e você encontrará o usuário final fazendo alterações e consumindo o tempo todo.

O pior caso de um 'primeiro e o outro' é quando você chega à outra parte e descobre que ele não se encaixa no design.

Assim, construa ambos. Mostre o progresso no front-end, faça o back-end funcionar com o que você está construindo. Em muitos casos, é uma boa ideia fornecer compilações incrementais e garantir que você esteja fazendo o que o cliente deseja (isso entra no Agile). Se demorar demais com 'avanços visíveis' pode prejudicar o relacionamento com o cliente (isso ocorre nos dois casos de 'tudo parece ser feito cedo' e 'nada é feito até o fim' - é difícil para o cliente ver a estrutura sendo escrita ou testes de unidade ou higienização de dados conforme o progresso).

Joel escreveu sobre isso em O segredo do iceberg, revelado :

Corolário importante dois. Se você mostrar a um não programador uma tela com uma interface de usuário 100% bonita, eles acharão que o programa está quase pronto.

Pessoas que não são programadores estão apenas olhando para a tela e vendo alguns pixels. E se os pixels parecem formar um programa que faz alguma coisa, eles pensam "oh, Deus, quanto mais difícil seria para fazê-lo realmente funcionar?"

O grande risco aqui é que, se você zombar da interface do usuário primeiro, presumivelmente para que você possa ter algumas conversas com o cliente, todos pensam que você está quase terminando. E então, quando você passar o próximo ano trabalhando "escondido", por assim dizer, ninguém realmente verá o que você está fazendo e eles acharão que não é nada.

Isso é reiterado novamente na postagem do blog. Não faça a demonstração parecer concluída, com este gráfico útil:

Como é feito o que parece

Observe aqui que as duas opções geralmente refletem o 'faça a interface do usuário' (e a expectativa é que você faça isso em breve) e 'faça o back-end' (e então o cliente está preocupado com a falta do prazo).

A aparência de algo 'pronto' deve corresponder à aparência de algo 'pronto'.

Todo desenvolvedor de software já passou por isso muitas vezes em sua carreira. Mas as ferramentas de editoração eletrônica causam a mesma dor de cabeça para os escritores de tecnologia - se você mostrar a alguém um rascunho que está perfeitamente tipificado e formatado, eles o veem como mais feito do que você gostaria. Precisamos de uma correspondência entre onde estamos e onde os outros percebem que estamos.

Este artigo também traz um ponto importante sobre o tipo de feedback que você recebe com diferentes níveis de integração da interface do usuário. Se você tem algo que parece completo, é mais provável que obtenha feedback sobre "você pode alterar a fonte" do que "esse layout não funciona - há muitas guias".


Para aqueles que estão lutando com isso no mundo do Java Swing, há uma aparência chamada Napkin que faz com que a interface do usuário não pareça completa (mesmo que seja).

A chave aqui é torná-lo para que não pareça pronto. Ter a interface do usuário concluída é um sinal para muitos usuários de negócios de que o aplicativo está completo (mesmo que sejam apenas algumas páginas estáticas sem lógica por trás dele ou algo construído em um construtor de interface).


Leitura adicional (e links do artigo):


7
Parece que você está propondo algum tipo de metodologia ágil ... :)
Alexander

7
@Alexander Agile ajuda nesse caso, mas não é essencial. O Waterfall pode ter marcos (entregáveis) e os clientes podem ficar muito desapontados ao ver o "parece feito, por que existem mais três quilômetros de milhas que demoram tanto tempo?" FWIW, já tive casos em que o usuário corporativo pensou que isso foi feito por causa da captura de tela + pintura no design técnico (loja em cascata).

3
No caso de você não ver uma resposta especializada para que o vídeo, aqui está: youtu.be/B7MIJP90biM
Ragol

3
Eu projetei interfaces de usuário para a maior parte da minha carreira em programação e, UMA VEZ, um cliente presumiu que uma interface de protótipo significava que o software estava "quase pronto". Parece-me que os apresentadores das interfaces de usuário de wireframe não estão fazendo um bom trabalho explicando os wireframes antecipadamente se os clientes de alguma forma confundem em pensar que o projeto está quase pronto.
Graham

2
+1 para guardanapo L&F. Isso certamente estará no meu futuro. :)
Kathy

27

Depende: você precisa de um loop de feedback apertado em torno de sua parte mais importante da funcionalidade

Se o núcleo do que você faz, a parte arriscada e assustadora, é algum mecanismo interno, faça com que a parte principal funcione, digamos, no console ou através de testes de unidade. Por exemplo, um analisador de protocolo não precisa de uma interface do usuário para saber se está funcionando corretamente.

Se a sua coisa legal envolve alguma interatividade - interatividade, você precisa estar constantemente solucionando problemas, jogando fora e redescobrindo - então uma abordagem de interface do usuário é crucial. Por exemplo, quero criar um aplicativo para permitir que as pessoas interajam com uma visualização de dados. A coisa mais importante que eu preciso descobrir é se a visualização é significativa, então provavelmente jogarei fora uma meia dúzia de abordagens antes de escolher uma. Farei tudo isso antes de escrever um único teste de unidade.

Há uma área cinza difusa entre o local onde você decide a melhor combinação de como interagir e validar melhor seu código (testes automatizados? UI para experimentação?). Eu pessoalmente fiz os dois extremos e tudo mais, e decidir o lugar certo para estar nesse espectro é uma das coisas mais difíceis que tenho que decidir e é 100% dependente do tipo de coisa que estou construindo.


2
Ou seja, identifique e resolva os componentes mais arriscados e críticos com antecedência, para reduzir a chance de excedentes e / ou falhas. Se esses componentes são a interface do usuário, lógica de negócios, etc ... ou, provavelmente, alguma combinação de todos os vários componentes.
284 Alexander

1
Realmente parece que você está falando de prototipagem para mim, porque se você ainda está jogando designs fora, é nisso que você deve estar repetindo - não no código real.
Aaronaught 29/07

8

Em um ambiente ágil, você pode ouvir discussões sobre "esqueletos ambulantes" ou "fatias verticais finas". A idéia é que, como o software de trabalho é o que é importante para o usuário, você o constrói de uma forma que funciona peça por peça.

No aplicativo de exemplo que você mencionou, você começaria com a janela e talvez uma guia e faria tudo funcionar de frente para trás de alguma maneira. Com o tempo, você adicionaria funcionalidade e, portanto, guias caso a caso, fazendo com que cada recurso funcionasse à medida que o construía. Isso faz parte do que as demonstrações frequentes dos clientes oferecem: uma chance de mostrar algo novo funcionando e obter feedback instantaneamente.

Em resumo, sim, o trabalho da interface do usuário é absolutamente parte integrante de uma unidade de trabalho funcional, se você tiver uma interface do usuário.

Comece com algo pequeno que funcione e repita sua funcionalidade para fornecer um software completo.


+1 É sempre essencial ter uma peça que possa ser entregue para entrega.
JensG

@ Jens: "Sempre é essencial ter um pedaço que possa ser entregue para entrega" é um canard. Na melhor das hipóteses, esse ditado se aplica apenas a uma minoria de aplicativos de software. No mundo real, os aplicativos que fazem apenas parte do trabalho necessário não são úteis nem um pouco.
Dunk

Essa é a sua experiência. Eu tenho diferentes. Projetos grandes e reais, com muitos marcos e clientes reais incluídos.
JensG

1
@ Dunk: Um aplicativo que não faz parte do trabalho é menos útil do que um aplicativo que faz parte do trabalho. No entanto, não estou falando de um aplicativo "pronto"; Eu estou falando sobre a ordem que se deve construir um aplicativo. Minha experiência é congruente com o JensG: sempre poder cortar um beta com base no que você demonstrou naquela semana e enviá-lo para os clientes imediatamente os torna muito mais felizes.
28414 Keith B

Esta é a única resposta com a qual posso me identificar. Os outros nem parecem considerar a possibilidade de que o bom desenvolvimento de produtos não se decomponha claramente em "UI" e "back-end". É uma pergunta que apenas um programador iniciante ou gerente de projeto poderia fazer, e não uma pergunta que um programador ou gerente experiente deveria se dignar a responder pelo valor de face. A própria idéia de perguntar o que deve ser "feito primeiro" fede a cachoeira.
Aaronaught 29/07

3

Eu recomendaria fazer uma mistura de funcionalidade e interface do usuário (e obter feedback ou experiência de teste o mais rápido possível).

BTW, não é assim que a maioria dos grandes softwares de GUI é desenvolvida? Veja, por exemplo, o navegador Firefox : de uma versão para a outra, tanto a funcionalidade quanto a interface do usuário evoluíram.


2

Em aplicativos grandes (baseados na Web PHP) em que trabalho, tento colocar as classes e métodos em primeiro lugar, que retornam valores fictícios . Isso é para estabelecer um pseudo-contrato que os outros desenvolvedores podem usar para implementar a interface do usuário.

Uma vantagem secundária desse método é que podemos aprimorar o contrato / interface conforme os requisitos da interface do usuário mudam (e eles sempre mudam), mesmo antes de todo o código ser escrito e entregue.


Isso é algo que estou tentando fazer. Como meu projeto específico é implementado como um enorme shell de interface do usuário e todo coletor de dados é um plug-in, cada plug-in é responsável por gerenciar seus próprios componentes de interface do usuário. Dessa forma, não há "contrato" necessário para uma determinada pessoa / grupo de pessoas. A suposição é que o mesmo grupo de pessoas esteja trabalhando em um determinado plug-in do início ao fim. É parte da razão pela qual estou projetando do jeito que sou. Como alternativa, para outros projetos, este é um excelente conselho. Tão positivo de mim, pois será útil para os outros.
RobotHumans

2

O que costumo fazer é começar com uma interface de usuário de baixa qualidade : algo que apenas despeja os dados variáveis ​​na tela. Sem fontes, sem alinhamento, nada gráfico por um longo tempo. Apenas "Welcome user x" e os botões chamados "load pic" etc. O que é bom nisso é que você descobrirá se algo no back-end está quebrado.

À medida que o desenvolvimento avança, você pode descobrir que mais coisas precisam continuar ou menos. Mas, em algum momento, você decidirá que o back-end está quase completo. Agora você tem uma interface do usuário que contém todos os anexos necessários e pode gastar muito tempo fazendo todo o material gráfico.

Cuidado, porém, não é infalível. Você precisa de um pouco de previsão para ver certos problemas surgindo. Por exemplo, pode ser necessário pesquisar componentes da interface do usuário para exibir os dados de maneira sensata.


E onde o cliente entra em jogo na sua metodologia? Lembre-se de que geralmente seu cliente tem apenas uma ideia geral do que deseja. Cabe a você descobrir como "extrair deles" exatamente o que eles querem, para que você possa construí-lo. Sua metodologia acabou de criar o que você acha que o cliente deseja, mas isso raramente será o que o cliente realmente deseja. Você acabou de perder uma tonelada de tempo codificando algo que o cliente não deseja.
Dunk

Ah, meus "clientes" estão sentados ao meu lado, e eu tenho um histórico em campo que me dá uma boa idéia do que é desejado. Basicamente, estamos sempre próximos do produto final, em termos de interface do usuário, e sempre posso obter feedback. Eu não tinha considerado o problema de ter um longo ciclo de feedback. Eu acho que ter o conhecimento do domínio é fundamental.
Carlos

0

Se você usar um bom marco e um sistema de rastreamento de problemas, poderá evitar alguns desses problemas porque, de relance, o gerenciamento pode ver o quão produtivo você está sendo. Eles verão que você concluiu 80% do back-end e que a interface do usuário é o próximo marco; eles poderão ver que você tem um conjunto de tarefas de interface do usuário e de back-end para concluir um marco de recurso específico. Mas tudo começa com os requisitos do projeto, e a resposta de Doug T levanta alguns bons pontos sobre esse aspecto do design de um sistema.


0

Pense no ponto de vista dos usuários / cliente. Um sistema de software é uma coleção de recursos que dão valor a esses usuários / clientes. É claro que cada um desses recursos possui uma interface do usuário, um back-end e outras coisas.

Crie seu sistema sempre recurso por recurso e tente dividir em recursos muito pequenos. Dessa forma, você está sempre perto de ter algo a mais para oferecer aos seus clientes, lembre-se de que o desenvolvimento de software não consiste em construir a versão 1.0, mas em ir para a versão 1.0.1 para a 1.0.2 e assim por diante ...


0

Depende. Quão bem definidas são suas necessidades? Quanto do sistema está voltado para a interface do usuário?

Pela minha experiência, a maioria dos clientes não sabe o que deseja até ver algo na frente deles. Por isso, normalmente forneço alguns frames dos principais aspectos da interface do usuário ou entrego a maioria da interface do usuário (não funciona). Isso permite que o cliente mude de idéia sobre os recursos / funções sem muito impacto, pois o design do banco de dados e a estrutura de código ainda estão apenas na fase de design - é fácil alterar o design. É uma ordem de grandeza mais fácil / rápida alterar o design no início do projeto do que no futuro.

O Agile afirma que você também deve trabalhar primeiro nos itens mais difíceis e nos itens mais importantes. Falhe rápido . Portanto, assim que o cliente visualiza a interface do usuário, concentro-me em criar pequenos componentes que são totalmente funcionais, falando o mais importante e o mais difícil de implementar primeiro, para que você saiba o mais rápido possível se vai encontrar algum obstáculo.

Então você tem seus sprints e mantém uma comunicação constante com o cliente, desenvolvendo os aspectos funcionais e da interface do usuário em algum momento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.