O Design e a Interface no mundo da Programação

O Design e a Interface no mundo da programação

... ou “Como acabar com as guerras civisno desenvolvimento de um produto”

Eduardo Shiota Yasuda | Dev in Sampa 2010 | 15.08.2010

Uma (breve) introdução

@shiota:

3 anos de Ciência da Computação

[quase] Formado em Design

Trabalha com Front-end, UX e Design

Irmão do @shadow11 - back-end jedi developer

Problema

O desenvolvimento de um produto é prejudicado por conflitos e falta de comunicação

entre design, front-end e back-end

Objetivo

Identificar papéis e obrigações de cada um, unificar o time e estabelecer uma metologia

eficiente de desenvolvimento

história da Interwebz como consertar? como continuar? exemplos

Como as interfaces evoluíram e os papéis mudaram

História da Interwebz


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1991

Primeira página HTML por Tim Berners-Lee


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1996

Entrada das empresas na Web

Netscape Navigator 2

Internet Explorer 3

JavaScript

ASP 1.0


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1996

Yahoo! e UOL - 1996Fonte: The Wayback Machine


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1996

Designers Front-end Devs Back-end Devs

Fazem imagensDesenham “layouts”

Desenvolvem o sistemaFazem o HTML e colocam as imagensAtualizam o conteúdoModificam os layouts


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1998

HTML 4.0

CSS 1

Macromedia (R.I.P.) Dreamweaver

PHP 3

Mozilla


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1998

Yahoo! e UOL - 1998Fonte: The Wayback Machine


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1998


Fazem imagensDesenham layouts

Desenvolvem o sistemaFazem o HTML e colocam as imagensInterações com JavaScriptAtualizam o conteúdoModificam os layouts


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1999

Explosão “ponto-com”

Photoshop com slices e “Save for Web”

Macromedia (R.I.P.) Flash 4


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

1999

Yahoo! e UOL - 1999Fontes: The Wayback Machine & UOL História


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2000~2002

Redesign das páginas

Introdução da Arquitetura da Informação, Usabilidade e User Experience na Web

Surgimento do Front-end Developer


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2000~2002

Yahoo! @ 18-18-2002 e UOL @ 2001Fontes: The Wayback Machine & UOL História


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2000~2002


Wireframe das páginasDefinem interaçõesDesenham layouts

Desenvolvem o sistemaInterações com JavaScript

“Cortam” os layouts em imagensHTML, geralmente com tabelas e estilos inlineInterações com JavaScript


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2003

CSS Zen Garden

Movimento Tableless

Safari


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2005

YouTube

Orkut

Ruby on Rails

Firefox & Safari 2


2006

Moda “Web 2.0”

Crescimento do uso do AJAX

Internet Explorer 7 & Firefox 2

1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010


2007

iPhone

Ruby on Rails no Mac OS X

Safari 3

1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010


2009

Explosão do mercado mobile

Internet Explorer 8

Firefox 3.5

Safari 4

Google Chrome

1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010


2010

Crescimento do HTML5 e do CSS3

iPad

Apple x Flash

Morte do IE 6 (pelo Google)

1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2010

Yahoo! e UOL @ 10-08-2010


1991 1996 1998 1999 2000-02 2003 2005 2006 2007 2009 2010

2010


Wireframe das páginasDefinem interaçõesDesenham layouts

Desenvolvem o sistema“Cortam” os layouts em imagensEstrutura semântica do HTML e CSS Orientado a ObjetoInterações avançadas com JavaScriptOtimização de carregamento da página

Identificando os problemas de comunicaçãoe conflitos entre as áreas, e solucionando-os

Como consertar?

Designers

Front-endDevs

Back-endDevs

Stakeholders

Testers

Managers


O Problema


O Problema


São os únicos que se envolvem com o P.O./Stakeholder/Cliente e testers

Não possuem conhecimento em front-end ou back-end, e elaboram features complexas/impossíveis para o tempo disponível

Alteram layouts ou funcionalidades e comunicam de última hora (ou não comunicam)

São inflexíveis em simplificar o layout ou interação para diminuir o tempo de desenvolvimento

Desenvolvem o sistema, mas devolvem dados incompletos/mal formatados

Desenvolvem o sistema, mas não criam as views certas

Fazem alterações no ambiente de desenvolvimento (migrations, gems, configurações da aplicação) e não comunicam o Front-end Dev

Não auxiliam ou ensinam o Front-end Dev a instalar, configurar e utilizar recursos

Enxergam o produto como programadores mas nunca como usuários

Não seguem corretamente o layout e as especificações dos Designers

Não sabem integrar o HTML ao sistema desenvolvido, deixando que um Back-end Dev o faça

Não possuem conhecimento suficiente de JavaScript, consumindo tempo do Back-end Dev

Se recusam a configurar ambientes e aprender sistemas de versionamento

Designers

Front-endDevs

Back-endDevs

Stakeholders

Testers

Managers


A Solução


A Solução

Um único time: Design + Front-end + Back-end

Um único objetivo: fazer o melhor pelo time, pelo P.O., e pelo usuário

Trabalho constante junto ao P.O.

Transparência entre todos

Compartilhamento de conhecimento entre as áreas


A Solução


Devem saber o básico (de preferência o intermediário) de Front-end Development

Deve ter uma noção e se interessar pelo trabalho dos Back-end Developers

Devem comunicar alterações de layouts e funcionalidades a todos o quanto antes

Devem estar dispostos a simplificar o layout/funcionalidade (e lutar por isso contra o P.O.)

Devem ter conhecimento básico de Front-end

Devem produzir as views e imprimir os dados corretamente

Devem auxiliar o Front-end Dev caso haja problemas ou dificuldades com a view

Devem ter uma noção e se interessar pelo trabalho dos Designers, esclarecendo quaisquer dúvidas técnicas

Devem estar em contato constante com os Designers, de preferência opinando construtivamente na interface

Devem seguir as especificações do layout e das funcionalidades, consultando os Designers caso haja dificuldades

Devem ter conhecimento na linguagem de Back-end, em ferramentas de versionamento e o básico do básico de infra para rodar o ambiente


A Solução

Fim do egocentrismo na própria área


A Solução

“Eu não vejo diferença entre Front-end e Back-end developer. Pra mim, são todos developers e devem ser tratados igualmente.”

Ronaldo Ferraz (@rferraz)

Sugestões de workflows e organização para mantera equipe sincronizada e funcionando

Como continuar?


1. Wireframes


1. Wireframes

Colombia TravelFonte: www.wireframeshowcase.com


1. Wireframes

Documentam as features (e desejos do P.O.)

Ajudam o P.O. e o tester a enxergarem melhor as features

Estruturam a página para que o HTML seja feito

Documentam funcionalidades da interface

Deixam claro aos Back-end Devs as funcionalidades do sistema e dados a serem impressos

Facilitam a estimativa das histórias


2. Meetings

Fonte: icanhascheezburguer.com


2. Meetings

Daily meetings, plannings, reviews e retrospectives devem envolver todos (designers, front-end e back-end devs)

Meetings que envolvem todos não devem entrar em detalhes técnicos – discutir isso separadamente

tempo++ == stress++ == harmonia--


3. Tech talks


3. Tech talks

Fonte: @taq - http://twitpic.com/2engls

http://twitpic.com/2engls

http://twitpic.com/2engls


3. Tech talks

Compartilha o conhecimento entre todos

Quebra a rotina do trabalho

Promove skills sociais

Slides/vídeos/anotações servem como referência posterior


4. Work!ow


4. Work!ow (Scrum)

O wireframe de cada história deve ser feito separadamente em outra história, um sprint antes

Histórias devem ter design, front e back-end simultâneos, em constante comunicação

Testes devem ser constantes

Todos devem tirar quaisquer dúvidas com o P.O. diretamente – design, front e back-end estão no mesmo “nível”


4. Work!ow (Scrum)

Sprint n Sprint n+1Sprint n-1

Wireframe/UX Design

Interface Dev.

Back-end Dev.

Testes

Bug fix& deploy

Planning 1 & 2Wireframe é apresentado e explicado

Planning 1 & 2Wireframe é apresentado e explicado

O que deu certo e o que deu errado

Exemplos

Recapitulando...

Recapitulando...

Design: Protótipos, Wireframes, Arquitetura, UX, Arte

Back-end: Sistema, oferece toda a funcionalidade e dados necessários à interface

Front-end: Interface que conecta o back-end ao Design

Recapitulando...

Design, front e back-end devem formar um único time

Todos devem compartilhar conhecimentos e acabar com barreiras entre as áreas

Todos devem prontamente auxiliar outras áreas

Todos devem se interessar pelo trabalho das outras áreas

Todos devem cuidar para que todos façam suas tasks com perfeição

Recapitulando...

Wireframes: devem ser feitos com antecedência, ajudam (muito) a mapear funcionalidades e fazer estimativas

Meetings: rápidos, somente o necessário, envolvendo todos

Meetings: discussões técnicas somente com a sua área

Tech talks: ajudam a passar o conhecimento

Workflow: todos simultaneamente na história, evitando o formato waterfall

Obrigado!Eduardo Shiota Yasuda - @shiota

[email protected]

http://www.eshiota.com

http://www.eshiota.com

O Design e a Interface no mundo da Programação

Technology

Transcript of O Design e a Interface no mundo da Programação