Category — web development

Foram quase seis meses de desenvolvimento intenso, layouts e mais layouts rabiscados, algumas discussões quase homéricas, mais rabiscos em layouts, mais modificações, e, claro, mais discussões até que chegamos a um coeficiente nada comum, e ontem lançamos a v2 do novo BlogBlogs.

novo BlogBlogs

[Read more →]

Pode não ser novidade para muita gente, já que o lançamento foi na quinta-feira, 17 de julho. Depois de um super sprint que começou às 10 horas de quarta-feira, e só terminou lá pelas 21h de quinta, o a versão beta do Brasigo foi ao ar.

O excelente trabalho de todo o time que esteve reunido durante esse tempo. Apesar de não fazer parte do time do Brasigo, e sim do Blogblogs, estive com o pessoal o tempo todo, as telas de erro, pelo menos elas, são obra desse escriba, o layout é obra do Marco Noleto, excelente designer, css e xhtml distribuidos entre Shiota, Noleto e Menga, programação por conta da Thais Camilo, Georges Benatti, William Fernandes, Jean Uchoa, Nando Vieira, arquitetura de software por Ronaldo Ferraz, conteúdo por conta da Lili Abdalla e Nitz Finkelstein, todos comandados pelo product owner do Brasigo, Bruno Alves. A equipe do blogblogs também deu uma força, com Manoel Netto, Lucas Húngaro, Rafael Apocalypse, e Tino Gomes, infra-estrutura por conta da dupla Marcus Vinicius Ferreira e Conrado De Biasi, e claro o maestro disso tudo Manoel Lemos.

Se você ainda não conhece o Brasigo, dá uma passada lá, garanto que você vai gostar, se você já é um usuário do blogblogs, use seu login e senha do blogblogs para acesar o Brasigo.

Sim, de certa forma o título deste post é uma referência ao livro do Luli, design web/design [bom lembrá-lo que ainda esperamos a 3a. edição do livro!], mas a referência termina aqui.

No começo de junho, David Heinemeier Hansson, escreveu no Signal Vs. Noise, o blog da 37Signals, um excelente post defendendo a idéia de que o designer deve ser o responsável pela implementação dos layouts que faz. Durante alguns dias pensei em postar sobre isso, contando minhas experiências, como designer, como implementador e como designer+implementador+programador ou webfaztudo. Posterguei esse post até hoje, quando li um outro excelente texto no Diary of a Web Site, Ding Dong the photoshop only web designer should be dead.

Quando comecei a trabalhar com internet, lá em 1997, era muito comum que designers não produzissem seus códigos, por ser novidade, escrever código era coisa para nerds malucos, e não para designers cools, além disso o trabalho era muito complexo, tabelas dentro de tabelas, e incontáveis gifs transparentes de 1×1 pixel, mais conhecidos pelo maldito nome de spacer.gif. Com o passar de alguns anos, isso piorou ainda mais, o advento de alguns softwares que eram capazes de exportar as imagens dos layouts fatiados para htmls montados, facilitou o trabalho dos designers, e a figura do ‘implementador’ perdeu status.

Quando o movimento pelos padrões aportou no Brasil mais uma vez vi a turma se separar entre designers e implementadores, aqueles que criavam e aquelas que escreviam css+xhtml e faziam mágica ao lançar sites sem spacer.gif e sem tabelas aninhadas dentro de outras tabelas aninhadas dentro de outras…

Hoje existem centenas de micro-empresas implementadoras de layouts, algumas no Brasil mas a grande maioria no exterior, que prometem entregar seu layout psd, em css+xhtml, validado em sei-lá-quantos sites/sistemas diferentes, e num prazo que faz mesmo a gente querer contratar o serviço, o preço também costuma ser bem baixo.

O grande problema nesses serviços bem como nas equipes onde o designer não participa em nenhum ponto da implementação dos layouts que produz, é percebido quando o que foi projetado no photoshop, não pode ser implementado exatamente como planejado, ou quando alguma modificação é necessária no layout para que este possa ‘encaixar’ no CMS. Nestas horas só o designer que pensou o projeto é capaz de corrigí-lo sem que o prejuízo seja grande.

Outro fator importante para que designers implementem seus próprios layouts é que muitas vezes, alguns recursos não podem ser reproduzidos pelas imagens estáticas que o designer gera, e na hora de aplicá-los, a pessoa responsável pela implementação, muito provavelmente não irá pensar da mesma forma que o designer pensou e o risco de algo dar errado é muito grande.

Quando o designer conhece o meio, i.e. a internet, conhece o CMS em que o site vai ser implementado, seus pontos fortes e fracos, seus limites, plugins disponíveis, etc… já no processo de planejamento e layout ele pode prever se determinadas coisas funcionarão ou não. E evitar re-trabalho no processo de criação.

A web não é uma rede de computadores, e sim uma rede de pessoas. Você já ouviu/leu essa frase antes, e ainda ouvirá muitas outras vezes, tenha certeza.

Até mais ou menos o ano 2000 o app de instant messenger mais usado por aqui era o saudoso ICQ, muito bom aplicativo, mas com uma interface de dar dó, que infelizmente nunca foi melhorada, muito antes pelo contrário, parece piorar a cada versão. A esperta Microsoft aproveitando-se disso lançou o limpo e prático MSN Messenger, que depois virou Windows Live Messenger, e ganhou os usuários brasileiros.

Calma, não foi tão simples assim, não… não foi. Primeiro as algumas pessoas passaram a usar o Msn, então os amigos dessas pessoas, também foram para o Msn, e assim por diante. Esse movimento vem se repetindo e se repetirá ad-eternum, até que todos os apps passem a conversar de maneira simples e eficaz.

As pessoas estão onde existem outras pessoas. As salas de chat se esvasiaram e hoje você raramente entra em uma sala de chat, simplesmente porque não há ninguém lá, mas em 1997 todo mundo frequentava os chats, porque era lá que estavam as pessoas.

No começo de 2007 apareceu o Twitter, ferramenta de micro-blogging, eu fui um dos primeiros usuários, e como não tinha ninguém por lá, abandonei-o. No final de 2007, pouco antes do intercom a Simone me chamou a atenção pro twitter, que já tinha alguns usuários, e adivinha, me tornei usuário assíduo. Com o intercom veio o boom do twitter, no Brasil, e todo mundo passou a usá-lo.

O número de usuários aumentou muito no mundo inteiro e o twitter começou a sofrer com o excesso de informações, ficou lento, caiu, ficou fora do ar, deu paus e mais paus. Acontece, faz parte não é mesmo? Então os usuários insatisfeitos começaram a tentar gerar um exôdo para outras ferramentas, como o Jaiku, do Google, o Pounce, e mais recentemente o Plurk.

A falta de simplicidade e facilidade de uso desses outros webapps fez com que boa parte dos usuários do twitter optassem por esperar que este resolvesse os problemas e voltasse a funcionar normalmente, o que ainda não aconteceu, mas nenhum desses outros serviços tem tantos usuário quanto o twitter, e dúvido muito venha a ter.

A moral da história? Conquiste seu usuário, seja usável, torne a navegação, o uso, da sua ferramenta agradável. Convença as pessoas de que vale à pena usar o seu aplicativo, e em pouco tempo todo mundo estará por lá? Sabe porque? Porque a internet é feita de pessoas, e pessoas gostam de pessoas, não de maquinas.

Há alguns anos, não muitos, clientes imploravam por contratos de manutenção de sites. A produtora era contratada não para apenas desenvolver o site, criar layout e aplicar a um determinado cms, ou criar layout e uma ferramenta de administração de conteúdo pro site. Os contratos para criação geralmente incluíam algumas horas de manutenção, onde a produtora poderia tanto desenvolver mais seções, criar mais páginas, instalar novas ferramentas ou simplesmente dar ‘ctrl+c ctrl+v’ num novo conteúdo que o cliente havia preparado, ou que a assessoria de comunicação do cliente enviara horas antes.

Com o tempo os clientes descobriram que boa parte das produtoras apenas faziam o ‘ctrl+c ctrl+v’ daquele conteúdo, raramente tratavam as fotos ou as preparavam para web, nem se fala então em um ‘copidésqui‘ dos textos. O resultado disso, não só disso claro, foi a crescente busca por contratos de desenvolvimento onde no final o cliente recebe o site, um cms, e dá adeus à produtora.

O custo de manutenção do site, nesse caso, cai drasticamente, já que o cliente das duas uma, ou vai ele mesmo atualizar o conteúdo do site, ou então vai pedir para a secretária ou algum outro funcionário, que se destaca pela fluência no ‘portuguêis‘, atualizar o site.

Em pouco tempo o cliente terá um site estilo frankenstein com fotos sem qualidade e textos ainda piores. Não muito diferente do que algumas produtoras entregavam em 2000 e alguma coisinha.

Posso chutar que uns 85% dos meus clientes me pedem sites com ferramentas de administração de conteúdo, porque eles não sabem html, não querem aprender, e morrem de medo de ficarem presos a contratos de manutenção, onde a produtora detêm todo o controle sobre o site, e se o cliente quiser mudar de produtora, a atual fará de tudo para atrapalhar a vida do cliente.

Concordo que a realidade econômica de muitas empresas, principalmente as de pequeno e médio porte, que são os uns 95% dos meus atuais clientes, não podem se amarra em contratos de manutenção, e que em boa parte dos casos precisam apenas atualizar uma seção de notícias, mudar um ou outro texto no site, quando muito os clientes precisam de atualizar uma foto, colocar algumas fotos numa galeria, ou mudar uma tabela de preço de produtos ou serviços, para isso, eu também concordo ser idiotice pagar por um contrato de manutenção.

Por outro lado, empresas grandes contratam produtoras maiores, que com equipes maiores tomam conta de 100% do site, das atualizações, de tudo. escolhem as ferramentas que preferem e ponto final. Seria esse o mundo ideal? Acredito que não.

É preciso haver um equilíbrio de forças nessa relação cliente-produtora/freela/designer/programador/whatever. Vejo clientes grandes que não conseguem manter os sites em dia e que ainda torram absurdos em fees de produtoras/agências grandes, e também vejo clientes pequenos metendo as mãos pelas pernas, por que não tem um auxilio profissional na hora de atualizar os sites.

A solução? Que tal um contrato de manutenção baseado sim em horas disponíveis, que ajudam as produtoras a manter o staff, mas que seriam usadas refinando o conteúdo que o cliente coloca no ar, tratando imagens de forma adequada, e procurando oportunidades pros clientes, novos negócios online, formas de anuncio, divulgação da marca, manutenção da imagem do cliente em comunidades/redes-sociais? Que tal quebrarmos esse paradigma de trabalho que já sabemos que não dá certo e estimularmos os clientes a terem, não só mais confiança na agência, mas a fazer da agência/produtora/programador/designer/freela/whatever um parceiro de negócios ao invés de apenas mais um fornecedor?

Ideiadigital é só uma marca que uso para assinar meus jobs como freela, mas de hoje em diante, procurarei me tornar mais parceiro de meus clientes e menos fornecedor de soluções encaixotadas… e você, arrisca entrar nessa onda? Navegar contra a maré e quem sabe fazer esse mercado um pouco melhor?