Programação orientada a layout

O que vou falar aqui talvez não seja grande novidade (afinal o que é que se fala que alguém já não tenha falado antes?), mas se trata de uma forma que gosto de pensar em por em prática um dia, sob uma rotina organizada e real.

Se trata de pensar como o cliente, e dar ao cliente o que ele precisa, logo de cara, para evitar alterações no sistema e tornar o processo de produção e desenvolvimento algo “palpável”, direto e real.

Tenho apreciado bastante Metodologias Ágeis, principalmente XP (eXtreming Programing) e isso tem tudo a ver com o que eu estou falando: a partir das iterações (reuniões periódicas), apresentar pequenas funcionalidades e etapas do projeto, ao invés de simplesmente estipular um prazo X e tentar correr para cumpri-lo, e até lá o cliente fica “na mão”.

Um ótimo livro que recomendo para a leitura que fala justamente disso é o “Getting Real” (Caia na Real, em tradução livre), recomendado pelo caríssimo Clavius Tales.

Pensando no layout primeiro

Uma das coisas que mais emperram um projeto é cliente que cisma com pequenas coisinhas do projeto. As vezes um tempo valiozo é perdido ajeitando-se “bugs” de layout, ou erros de português, enquanto que poderia-se estar desenvolvendo funcionalidades que tornariam o sistema realmente funcional.

Sendo assim, a prototipação entra em primeiro lugar. De que adianta mostrar ao cliente um cadastro sendo efetuado sob uma aparência completamente irreal? O próprio cliente se tornaria mais interessado e já teria “algo nas mãos” se o layout fosse pensado e realizado inicialmente, além de evitar que toda uma equipe seja deslocada para o desenvolvimento.

Não diria que tudo do sistema deveria ser desenhado previamente, mas ao menos todas as funcionalidades solicitadas para a primeira etapa do

Cito aqui um trecho do livro de Seth Godin: http://gettingreal.37signals.com/GR_por.php#ch09

Desenhe a interface antes de começar a programar

Muitos aplicativos começam com a mentalidade de programar primeiro. Isso é uma má idéia. Programação é o componente mais pesado de construir em um aplicativo, significando ser o mais caro e mais difícil de mudar. Ao invés disso, comece desenhando primeiro.

Design é relativamente leve. Um esboço de papel é barato e fácil de mudar. Rascunhos HTML são relativamente simples de modificar (ou jogar fora). Isso não é verdade na programação. Desenhar antes deixa você flexível. Programar primeiro prende você e gera custos adicionais.

Outra razão para projetar primeiro é que a interface é o seu produto. O que as pessoas vêem é o que você está vendendo. Se você somente rabiscar uma interface no final, os buracos vão aparecer.

Nós começamos pela interface para que possamos ver como o aplicativo será desde o começo. Este será constantemente revisado no decorrer do processo. Isso faz sentido? É fácil de usar? Ele resolve um problema de imediato? Existem perguntas que você só poderá realmente responder quando você lidar com telas reais. Desenhar antes deixa você flexível e o leva para essas respostas no processo mais cedo do que mais tarde.

WebDesigner e Designer de Interação têm espaço garantido

Já não dá mais para pensar em programar só código e desmerecer o layout. Lembre-se que a maior parte do contato que o usuário vai ter com seu sistema será o layout e as facilidades ou dificuldades que a interface irá proporcionar a ele. Não se dê ao luxo de não precisar de alguém que faça um design bacana do seu sistema, só para economizar uma grana com salário ou serviço “por fora”. Hoje em dia sistemas pouco intuitivos não têm mais espaço no mercado.

Sabe-se que a grande maioria dos usuários só utilizam uma pequena porcentagem das ferramentas que os sistemas dispõem. Então para quer pensar em tudo, e acabar oferecendo um trem complicado de pilotar? Por que não oferecer uma bicicleta para o seu cliente, e, aos poucos ir incrementando rodinhas e outras coisas mais até ela se tornar uma Harley Davidson?

O Designer de Interação tem a visão necessária para entender o que realmente precisa estar ali e o que é inutil para o cliente. Um exemplo bem prático é o MSN. Alguém já leu algum tutorial ou manual de MSN? Porém todos sabem mexer. É uma ferramenta simples, mas super útil. Pense bem nisso antes de querer fazer um sistema de chat com suporte a mediadores e diversas salas e sub-salas com usuários X que fazem Y coisas. Pense simples! Caia na real.

5 Comments

  1. Clavius Tales
    Posted agosto 15, 2009 at 8:54 pm | Permalink | Responder

    Fala, Gogas.

    “Programação orientada a layout”

    Prefiro “Desenvolvimento Guiado (ou Dirigido) por Leiaute”. A ideia de “desenvolvimento” dá uma visão mais ampla, das demais disciplinas. Prefiro “guiado (ou dirigido)” a “orientado”. Acho a palavra mais forte, no sentido do contexto mesmo. “Leiaute” pois gosto de aportuguesar palavras de uso corriqueiro. Houaiss cita registros de 1965. Aliás, me admirou muito um diletante na língua ter escrito “layout”. Mas o principal mesmo, o relevante, é a preposição “por”. Não tenho um bom dicionário de regência para me ajudar na explicação, ou até mesmo uma pesquisa no assunto, mas vou pela minha intuição mesmo. Vejamos.

    Duas frases que expressam as regências canônicas de “orientado”:

    – Ele foi orientado a varrer a sala.
    – Ele foi orientado por placas indicativas.

    É como se o seu título dissesse que os programadores devem produzir leiautes. Mas na verdade o que você quer dizer é que a programação deve ser orientada (guiada, dirigida) pelos (por + os) leiautes.

    Talvez você tenha caído numa pegadinha: o fato de Object-Oriented ter sido traduzido por Orientação a Objetos (OO). Ou Test-Driven Development (TDD), que é normalmente traduzido para Desenvolvimento Orientado a Testes. No primeiro caso, de OO, acho que há uma elipse. Algo mais ou menos assim: Orientação a (construir) Objetos. No caso de TDD, me parece que é a mesma pegadinha de OO. Você poderia argumentar: “Mas em Programação Orientada a Leiaute há elipses: Programação Orientada a (construir primeiro o) Leiaute.” É verdade, mas pra que complicar tanto? Ainda assim, mesmo com essa possível elipse, a frase com a preposição “por” é muito mais significativa.

    De qualquer forma, deixemos esse blablablá de língua que é o que menos interessa aqui. Título não vale quase nada. Ideias valem muito mais.

    “Uma das coisas que mais emperram um projeto é cliente que cisma com pequenas coisinhas do projeto. As vezes um tempo valiozo é perdido ajeitando-se “bugs” de layout, ou erros de português, enquanto que poderia-se estar desenvolvendo funcionalidades que tornariam o sistema realmente funcional.

    Sendo assim, a prototipação entra em primeiro lugar. De que adianta mostrar ao cliente um cadastro sendo efetuado sob uma aparência completamente irreal? O próprio cliente se tornaria mais interessado e já teria “algo nas mãos” se o layout fosse pensado e realizado inicialmente, além de evitar que toda uma equipe seja deslocada para o desenvolvimento.”

    Não é elaborar antes o leiaute que resolve esse probleminhas. Se for apresentado um leiaute com erros, o cliente vai do mesmo jeito perder tempo pedindo para corrigir, e a equipe (o “designer”) vai do mesmo jeito perder tempo corrigindo. Ou seja, o mesmo tempo é perdido, mas em momentos diferentes: elaborando o leiaute antes, antes da entrega; elaborando o leiaute durante o desenvolvimento, durante e depois da entrega. O correto mesmo é produzir certo na primeira vez.

    De fato, há uma questão psicológica que precisa ser levada em conta. Quando o cliente pede uma correção de um protótipo, ele tem a sensação de que aquilo é normal. Quando pede a correção na entrega, tem a sensação de que aquilo é retrabalho. Cabe esclarecermos o cliente de que se trata da mesma coisa. Outra questão é uma certa impedância, pois quando se está ali com o leiaute em mãos, é mais fácil fazer alterações. No outro caso, vai-se perder tempo reambientando a mente para o trabalho, abrindo o editor de HTML, etc. Mas esse tempo é tão curto que não sei nem se vale a pena considerar. De novo: o certo é fazer certo da primeira vez.

    Métodos ágeis indicam o uso de rascunhos, pois as relevantes questões de usabilidade se resolvem tranquilamente com essa ferramenta. Uma decisão entre um “combobox” e “radiobuttons” pode se resolver com rascunhos, por exemplo. A crítica que eu faço a rascunhos não é essa que você argumenta, mas sim a de que com um ferramenta como o Delphi (costumo prototipar em Delphi) você tem a oportunidade de fazer mudanças de forma muito mais fácil, ao invés de ficar usando borracha para fazer certas correções. Meu processo de prototipação com uma ferramenta de “software” é muito mais fluido. Além do mais, essas ferramentas podem ajudar em questões importantes de usabilidade. Por exemplo: vou precisar fazer “scrool” de tela ou crio abas? No papel, não dá para saber se aquilo tudo vai caber numa tela só.

    De qualquer forma, parabéns pelo “post”. Gosto muito dessa abordagem.

    • Henrique Gogó
      Posted agosto 17, 2009 at 5:41 pm | Permalink | Responder

      Tales,

      Vindo um comentário seu, sendo ou não favorável ao meu post, só tenho a agradecer.
      Quanto às questões de português, utilizar ou não estrangeirismos, eu como “um diletante na língua ter escrito ‘layout’ ” não soa nada controvérsio no meio acadêmico.
      Não querendo dar continuidade a discussões baseadas em pontos de vista ou posicionamentos quanto à utilização da língua materna, gostaria apenas de dizer a seguinte frase: “Sou a favor de uma gramática descritivista, e não normativa”.

      Quanto a todo o comentário propriamente dito sobre a programação orientada a layout, o que posso fazer é aprender. Confesso que não entendo tanto do assunto, mas vou formando aos poucos certos conceitos. Pode ser que eu venha a postar um artigo rebatendo esse que acebabei de escrever, mas não acho que de todo eu esteja errado. Talvez não tenha expressado a ideia por completo, mas o procedimento de prototipar inicialmente acredito que seja bem válido. Quanto à ferramenta de prototipação, vai da escolha pessoal.

      No mais, só a agradecer.

      • Clavius Tales
        Posted agosto 17, 2009 at 9:29 pm | Permalink

        ■ Quanto às questões de português, utilizar ou não estrangeirismos, eu como “um diletante na língua ter escrito ‘layout’ ” não soa nada controvérsio no meio acadêmico. ■

        O que eu disse foi: é de se admirar o fato de alguém que estuda a língua preferir um estrangeirismo a seu correspondende vernáculo, dado que este já é registrado há tanto tempo. Guardadas as devidas proporções, seria a mesma coisa de vê-lo escrevendo “football” ao invés de “futebol”. Em geral, os que tem mais intimidade com a língua (que é o seu caso) são os primeiros a utilizar as formas vernáculas de palavras de origem estrangeira. Daí minha admiração em vê-lo escrever “layout”.

        ■ Não querendo dar continuidade a discussões baseadas em pontos de vista ou posicionamentos quanto à utilização da língua materna, gostaria apenas de dizer a seguinte frase: “Sou a favor de uma gramática descritivista, e não normativa”. ■

        Dois.

        ■ mas não acho que de todo eu esteja errado ■

        Se meu comentário pareceu isso, me desculpe. Como disse, gosto muito dessa abordagem de prototipar telas.

  2. Clavius Tales
    Posted agosto 15, 2009 at 9:04 pm | Permalink | Responder

    Esqueci de uma coisa: quede o endereço de assinatura (RSS) do teu blogue? Se está na página principal, evidencia mais pois procurei e não achei.

    • Henrique Gogó
      Posted agosto 17, 2009 at 5:48 pm | Permalink | Responder

      Opa! falha minha.
      Mudei o tema recentemente. Vou tentar colocar um iconezinho nalgum lugar do blogue visível. Espero que você o assine.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: