Simone Villas Boas

Entre o artigo anterior e este, foram seis meses onde fiz um curso para CSM, certifiquei-me, troquei de emprego e comecei trabalhar com outros projetos que integram equipes que usam metodologias de experiência do usuário e as que usam as metodologias de desenvolvimento ágil. Gostaria de compartilhar algumas destas novas experiências.

Durante o curso, surgiu o conceito de haver um time separado para ajudar o product owner a definir o backlog. Em um PO team podem estar contempladas várias competências que não estão relacionadas a desenvolvimento tecnológico, inclusive as de UX, como arquitetos de informação, designers de interfaces e até mesmo desenvolvedores front-end. Tudo depende de qual seja a definição de pronto (ou definition of ready – DoR) para o dev team começar suas histórias: layouts ou código HTML.

Nada impede que este time associado ao product owner seja uma célula própria e que siga os ritos Scrum como tal.

Um cenário

Em um projeto em que estou envolvida agora, a empresa que o implementou optou por não ser obrigatório encerrar uma história ao final de um sprint. Aceitar que uma história pode precisar de mais um sprint para ser concluída significa tempo para que as tarefas que gerem dependências podem ser feitas sem sobrecarregar alguns dos membros do time, como o front-end e o QA, sem que seja encarado como uma falha do processo (e do time). A estrutura básica de uma história de desenvolvimento simples pode ter os seguintes conjuntos de tarefas:

• Criar cenários de testes
• Desenvolver código server-side
• Desenvolver código HTML/CSS/JS
• Desenvolver código server-side (dependente do código HTML/CSS/JS)
• Testar (dependente de todas as tarefas anteriores)

É importante enfatizar o conceito de minimizar a dependência entre tarefas para não cair nos mesmos problemas de um modelo em cascata. A estrutura de um time e os processos envolvidos devem facilitar o paralelismo entre as tarefas de uma história para que idealmente se consiga iniciar e concluir uma história em um sprint. As dependências são problemas do mundo real que ficam mais explícito com a variedade de competências que uma história pode requerir. Por exemplo, para realizar testes funcionar é necessário que o desenvolvedor já tenha feito sua parte de acordo com o que foi planejado.

(De novo, o que exponho aqui são formas que alguns times do mundo real acharam para solucionar problemas. Tenho certeza que outros times por aí podem ter encontrado outras soluções bem mais fiéis ao framework.)

Neste cenário, o DoR inclui layouts e arquitetura que foram desenvolvidas pelo PO team ou por outra célula. Vemos aqui, de novo, que as histórias do designer não são as mesmas que as do programador. Muitas vezes, a visão de como o sistema deve funcionar não está completa até a aprovação do layout das telas.

Por outro lado, histórias podem ser criadas apenas para incorporar outras tarefas de UX, como testes de usabilidade. Estas histórias podem estar relacionadas a datas de releases, por exemplo.

Mais informações sobre Scrum podem ser encontradas no Agile Atlas.

Este artigo é uma continuação do texto “Criação + Scrum: como encaixar UX nas metodologias ágeis“, de 11/11/2012.

Artigos relacionados:

• Criação + Scrum: como encaixar UX nas metodologias ágeis
• Maturando o HTML
• O que você precisa saber sobre HTML5
• Morte ao Internet Explorer 6!
• Vixi, mas que letrinha miúda!

Andei conversando nos últimos dias com designers, arquitetos de informação e gestores que já estão trabalhando com metodologias ágeis. Notei que há muitas dúvidas de como a criação pode alinhar com desenvolvimento na prática. Vamos rever aqui alguns métodos de posicionamento das tarefas de UX dentro do modo de produção.

Obs.1: Não sou especialista em Scrum. Sou apenas mais uma parte desta engrenagem que luta diariamente para encaixar todas as etapas de crição de interfaces nas metodologias ágeis de desenvolvimento, com todas as dificuldades do dia-a-dia.

Obs.2: Esta não é uma regra e sim um estudo de caso. Cada empresa, assim como cada time, deve encontrar a melhor forma de adaptação à metodologia. Agências que possuem uma célula que lida com diversos clientes ou uma de dedicação exclusiva a um cliente devem se planejar de modo bem diferente.

Resumindo um pouco da terminologia que usamos na célula em que trabalho somente para referência:

• Célula: grupo de pessoas com competências diversas responsáveis por entregar as funcionalidades de um produto.
• Sprint: período de tempo para realização de uma entrega completa. Trabalhamos aqui com dez dias úteis.
• Planning: reunião do time com o PO para tirar dúvidas sobre as regras de negócios. É realizada no primeiro dia do sprint.
• Review: apresentação do trabalho realizado durante o sprint.

Nos casos estudados, contamos com os seguintes papéis e competências:

• Product owner (PO): traz as regras de negócio, representando os interesses de clientes e usuários.
• Scrum master: responsável por manter o ritmo da equipe, resolvendo impedimentos e atuando como mediador entre o time e outras áreas.
• arquiteto de informação e designer de interação: elaboram as interfaces, estabelecendo a navegação entre telas ou funcionalidades.
• front-end: responsável pelos métodos de codificação em HTML/CSS e da definição das tecnologias de interação (frameworks e plugins em JS).
• desenvolvedor: integra o sistema o código HTML sugerido, realiza alterações no sistema e testes funcionais.

Lembro que há situações onde um profissional pode execer duas ou mais competências. Um designer de interação também pode fazer as vezes de um arquiteto de informação, assim como um front-end pode trabalhar programar em linguagens server-side.

Em teoria, teríamos que idealizar, planejar, criar e desenvolver uma funcionalidade em dez dias. Isto certamente funciona bem para a criação de uma nova microinteração ou a evolução de uma funcionalidade onde as tarefas relacionadas às diversas competências podem ser realizadas paralelamente. Vamos analisar história de uma manutenção evolutiva e suas possíveis complicações:

História: Como usuário quero participar de uma enquete com foto.
Contexto: O time desenvolveu anteriormente uma funcionalidade de enquete em formato texto que precisa de evolução para atender uma nova necessidade do cliente.

1° cenário: um sprint
Sprint 1: O PO explica a nova necessidade e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas, enquanto os desenvolvedores alteram a funcionalidade. Após aprovação de layouts, o front-end corta em HTML/CSS e adiciona interação em JavaScript. O desenvolvedor integra o HTML ao código, publica em um ambiente de teste e todos validam.

Neste cenário, já encontramos alguns pontos de conflito. O time sente-se mais confortável em trabalhar com telas aprovadas pelo cliente/usuário. Nem sempre dentro do período de um sprint isto é viável. Consideramos que o review é o momento para a aprovação da entrega. Por que não aprovar também layouts, wireframes, fluxos de interação e relatórios de usabilidade?

2° cenário: dois sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, os layouts são submetidos para aprovação e a navegação sugerida é demonstrada.
Sprint 2: O front-end transforma o layout em HTML/CSS e adiciona interação com JavaScript. Ele também testa o modelo de navegação sugerido. O desenvolvedor integra o código HTML ao sistema e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam. Na review, a publicação de uma enquete com foto é demonstrada.

Parece que há perda de tempo neste cenário, mas isso não ocorre na prática. É possível tratar de mais histórias em paralelo. Na prática, é como se arquitetos de informação e designers estivessem em uma célula diferente que anda um sprint à frente.

(Na célula em que trabalho agora, trabalhamos boa parte das histórias em dois sprints. A diferença é que front-end faz sua entrega no primeiro sprint.)

Podem surgir outras complicações. Interações podem ficar mais complexas e demandar mais tempo de desenvolvimento exclusivo do front-end. Torna-se necessário aqui um sprint exclusivo para a montagem do layout em HTML, CSS e JavaScript.

3° cenário: três sprints
Sprint 1: O PO traz o conteúdo e solicita alteração no sistema durante o planning. O designer elabora navegação e as telas. Na review, são apresentadas as telas para atender à nova demanda.
Sprint 2: O front-end transforma o layout em em HTML/CSS e adiciona interação em JavaScript. Na review, são apresentados os protótipos funcionais.
Sprint 3: O desenvolvedor integra o HTML ao código e o altera segundo as novas demandas. Ele publica em um ambiente de teste e todos validam.  Na review, o sistema é apresentado completo.

Além disso, profissionais externos à célula, como analistas de usabilidade ou a equipe de infra-estrutura, podem demandar cortes durante o desenvolvimento para realização de testes. Os sprints mais cortados, quase que por competência, facilitam a integração com outras equipes. Nem sempre a interação leva apenas um sprint o que pode prejudicar o planejamento do time. No caso de testes de usabilidade, por exemplo, há fatores externos como seleção de usuários e agenda de laboratório. Tudo isso deve ser analisado história a história considerando os prazos negociados com clientes e usuários.

O terceiro cenário é o mais próximo do que considero bom hoje. É claro que demandaria um pré-planejamento de três sprints e nem sempre isso é possível.

Para fazer tudo isso funcionar, temos usado também o Kanban (que podemos ver em mais detalhes em outro artigo).

O importante antes de estabelecer uma forma de trabalhar é fazer as perguntas certas sobre o tempo e o nível de envolvimento entre todos os interessados. Além disso, nada impede que variáveis deste modelo podem ser usados como regra em todas as histórias, em histórias de um determinado sprint ou caso a caso. O melhor momento para esta definição é quando a demanda chega ao time que pode ser durante o planning ou em uma reunião anterior de priorização.

Como você e sua equipe trabalham? Tem alguma dúvida? Sugestão? Comente aqui!

Outras reflexões:

• A formulação da estratégia de experiência do usuário pode ser incompatível com o processo do desenvolvimento ágil. Deve-se concluir toda a pesquisa e desenvolvimento de UX em um Sprint 0 antes de começar o desenvolvimento.
  Is UX Strategy Fundamentally Incompatible with Agile or Lean UX?, por Paul Bryan (UX Matters).
• Por outro lado, o time de UX deve sentir-se confortável para parar o desenvolvimento e reavaliar conceitos mais amplos. No artigo Fitting Big-Picture UX Into Agile Development (Smashing Magazine), Damon Dimmick introduz o conceito de design spikes.

Artigos relacionados:

• Criação + Scrum: mais uma visão sobre UX e desenvolvimento ágil
• Maturando o HTML
• Desenvolvedores de front-end, uni-vos!
• Scroll monstro: O terror dos blogs
• Planejando interfaces Web acessíveis

Desde a onda de popularização dos smartphones iniciada com o iPhone, os grandes publicadores acharam que a solução ideal para o conteúdo nos dispositivos móveis estava nos aplicativos. A premissa era que a marca seria forte e apelativa o suficiente para fazer com que o usuário baixasse um app e o abrisse diariamente em busca de informação. O custo de desenvolvimento e publicação de um aplicativo na Apple Store ou no Android Market seria recompensado através de um investimento no fortalecimento da marca ou por assinaturas. Esta premissa foi válida para algumas empresas por algum tempo.

No entanto, o usuário se acostumou a acessar a informação de vários modos num dispositivo móvel. Por RSS, a informação chega a aplicativos agregadores de conteúdo gerenciados pelo usuário, como Flipboard e Newsify. O conteúdo pode ser compartilhado e pré-visualizado em diversos mecanismos de busca, Facebook e Twitter. Inclusive, há protocolos específicos para visualização de dados nestes sites como Schema.org, Open Graph Protocol e Twitter Cards. Se o usuário não dispuser de tempo, aplicativos como o Pocket (antigo Read it later) e Instapaper armazenam o link para ser lido (ou não) depois. Podemos mencionar também outros agregadores como displays em elevadores, shoppings e ônibus. A relação entre produtor e consumidor de conteúdo torna-se mais complexa a cada mês, a cada novidade no mercado.

E, por outro lado, o custo e o tempo prolongado para o desenvolvimento e a publicação de cada aplicativo para cada tipo de dispositivo torna todo o modelo frustrante para o publicador.

É irônico que os velhos e conhecidos websites ressurjam como a opção mais viável para os grandes publicadores através de metodologias como responsive design e mobile first. Ao que parece, os mesmos profissionais que lidam constantemente com as diferenças de renderização dos navegadores são os mais qualificados para lidar com os diversos tamanhos de telas dos dispositivos móveis e com as diferenças de interação de um aparelho para outro.

Há um ano, o Financial Times abriu mão dos aplicativos para investir em um web app. A Folha de São Paulo seguiu pelo mesmo caminho. O conteúdo do Terra abre diretamente no web app não importa a origem (mecanismo de busca, rede social ou agregador de conteúdo). Todos estes publicadores de conteúdo e vários outros estão procurando neste exato momento um modo de que a informação exista e possa ser vista em todo o lugar, dentro e fora dos sites oficiais, conservando a força da marca e fortalecendo seu modelo de negócio.

A informação pode ser acessada de vários modos. Ela deve estar disponível de modo completo e através da melhor experiência possível. É o dispositivo que determina a interface e não o local de publicação do conteúdo.

Isso acontece não só com o jornal que virou um site que virou um app ou um web app. É uma tendência midiática por vezes reconhecida como transmidia storytelling. É o programa da TV a cabo que você só assiste quando precisa de uma receita para o almoço de domingo.

Decretaram a morte da web cedo demais?

Mais:
Forbes: More Mobile News Consumers Choosing Web Over Apps
Folha de São Paulo: Ao encontro do que leitores preferem, ‘NYT’ adota HTML5

Artigos relacionados:

• A morte dos sites
• Desenvolvendo de acordo com os padrões Web
• Tags are the new black
• Brincando de Jogo dos 7 Erros
• Bloglines: Soluções para information junkies de plantão

Dois sites de compras coletivas promoveram esta semana um produto diferente. Longe dos milhares de cupons para tratamentos de beleza, jantares e hospedagens, estes sites venderam carros MINI Copper com 50% de desconto. A compra era possível para o primeiro mortal com um cartão de crédito com limite acima de trinta mil reais (ah, quem me dera ter um destes!).

Mas, como você já deve estar imaginando, os sistemas deste tipo de sites não suportam bem demandas muito altas ou promoções-relâmpago como estas porque não foram planejados para isso.

Para furar o Grupon, que divulgou a promoção alguns dias atrás, o ClickOn liberou a venda ontem um pouco antes da meia-noite com desconto de 57% no preço final do produto. Sem planejamento adequado aconteceu o (im)previsto: trinta usuários compram um mesmo carro no mesmo segundo sendo que apenas uma compra foi validada. Entre tantas acusações de fraudes, não vejo aquela que poucos têm coragem de fazer: quem foi que teve esta ideia?

O Grupon promoveu a mesma compra, sim, mas não sem antes criar um concurso cultural. Aquele que enviasse a melhor frase teria o direito a saber o horário da liberação da venda do carro. Concurso cultural é uma saída nada criativa, eu sei, mas funcionou! A promoção só não foi um sucesso completo pois o usuário vencedor não é o comprador do carro. Mas não há ninguém questionando a empresa, a venda ou o ganhador nas mídias sociais.

Promoções são válidas para promoção de marcas, produtos e serviços, mas requerem um planejamento adequado. E não há planejamento sem tempo, sem brainstorm, sem infraestrutura, sem consultar todos os departamentos envolvidos (sim, a tecnologia também, por que não?) e, principalmente, sem um plano alternativo. O timing de uma promoção é apenas um dos elementos a serem considerados e talvez nem é o mais importante.

Mais aqui: ClickOn fura Groupon e vende MINI One por R$ 29.999, mas processo gerou desconfiança

Artigos relacionados:

• O luxo na era das compras coletivas
• Fácil até demais?
• Os paradigmas da navegação off e on line
• Compras por impulso
• Consumindo guloseimas por atacado

Recebi agora um cupom-desconto do MyHabit  um novo e-commerce da Amazon com ofertas de grifes como Dolce & Gabbana e Puma. Babei na experiência do usuário com sua vitrine em vídeo e interface minimalista. Há algum tempo tenho acompanhado o Fab.com, que possui a mesma proposta só que com itens de design.

Estes sites fazem parte de uma tendência de evolução comercial dos de compras coletivas como Grupon e Peixe Urbano. A empresa fecha um acordo com produtos que precisam de visibilidade ou estão encalhados. A oferta fica disponível de um a três dias na loja virtual. Os usuários podem assinar a newsletter com as ofertas do dia. E sim, o email marketing será ainda por muito tempo uma das fontes primordiais de vendas no e-commerce.

Aqui podemos ver diversas oportunidades para investir no mercado de luxo. É uma indústria estável, com consumidores fiéis e que não entra em crise nunca. Vinhos, maquiagem, jóias, acessórios e gadgets, são vários os produtos que se encaixam em negociações de alto nível bem longe do perrengue dos salões de beleza e restaurantes. Mas será que esta será uma boa ideia para o mercado nacional, principalmente com a nova classe média que emergiu nos últimos anos? O que você acha?

Artigos relacionados:

• Compras coletivas se embolam no luxo
• Diminuindo o ritmo: eventos Web em dezembro
• Homus webicus
• A crise e o e-commerce 2.0
• Web 2.1: cautela e canja de galinha

Fui surpreendida pelas mudanças no Big Picture, a página de galerias fotojornalísticas do site do jornal do Boston Globe. A partir de agora, o usuário contribuir nesta seção somente através do widget de comentários do Facebook. Os motivos para esta mudança foram descritos desta forma:

Facebook é ubiquo; possui mais de 500 milhões de usuários ativos, 70% deles não são dos Estados Unidos. Está disponível em 70 idiomas. Era a melhor ferramenta que pudemos encontrar para servir a audiência mundial de fãs do Big Picture.
[referência]

O Facebook pode estar presente em diversos países e em diversas plataformas, mas será mesmo que as redes sociais significam o fim dos sites da Web como conhecemos? Questionei há um ano que o fim estaria nos aplicativos, um pouco antes de um famoso artigo na Wired afirmar que estava de fato nas redes. Há algumas empresas abrindo mão de desenvolvimento de sites tradicionais para criar e manter fan pages, mas esta sempre foi uma decisão de marketing baseado na estratégia do produto ou serviço e não uma decisão técnica.

Além disso, Facebook faz parte de uma nova leva de empresas favorecidas por um investimento maciço que vai na contra-mão da recessão europeia, americana e japonesa. Não precisamos ir muito longe para temer que esta é uma bolha que eventualmente pode explodir com consequências imprevisíveis. Mais que isso: sabemos que há um ciclo de vida entre nas plataformas digitais.

Por outro lado, quem disse que seu site vai durar mais que o Facebook? Devemos estar preparados para surfar em cada grande onda da internet?

Os comentaristas possuem a opção de compartilhar seus comentários no site com seus amigos no Facebook, que poderão ser apresentados às fantátiscas fotografias do Big Picture.

Neste ponto, não resta dúvidas para ninguém. As redes sociais hoje são responsáveis por grande parte do tráfego na maior parte dos site e blogs que conhecemos. É provável que estas fontes devem passar os mecanismos de busca em número de acessos.

A qualidade dos comentários deve melhorar com as pessoas usando seus nomes verdadeiros.

Aqui temos uma premissa falsa ou um falha em definir “qualidade em comentários”. Boa parte dos comentários destas fotogalerias são tão resumidas quanto um “curti”, e um “curti” em diversos idiomas. Se antes os usuários temiam em comentar em seu idioma local, agora não há motivo para tanto. A quantidade de comentários certamente cresce. E a qualidade do debate melhora junto?

O que você acha?

Artigos relacionados:

• No final, o que é melhor para o usuário?
• Incentivando a colaboração do usuário
• Novo layout
• Nostalgia
• A usabiliteira contra a legião dos sem-noção

HTML5 está sendo discutido por todo lado. Natural. É a grande novidade da década no desenvolvimento para a Web. Depois de anos de indas e vindas com o XHTML2, W3C se uniu aos dissidentes do WHATWG para continuar desenvolvendo a especificação do HTML.

As maravilhosas oportunidades do HTML5 você pode ver no HTML5 Demos and Examples, no HTML5 Gallery ou no HTML5 Watch. Mas o que de fato você precisa saber antes de tomar uma decisão em aplicar este tipo de documento ao seu projeto?

Código mais frouxo

Nos últimos anos, a obsessão pelo código válido e bem formado nos fez esquecer o princípio do HTML: qualquer um pode escrever documentos e publicá-los na Web. Para quem trabalha com CSS e JavaScript, esta obsessão tem uma razão de ser. Qualquer trecho mal formado pode criar problemas de renderização indecifráveis. Nesta nova especificação, voltamos a não obrigatoriedade de fechar tags do HTML 4.

Além disso, o HTML5 permite tags escritas em caixa alta ou baixa. Quem tem TOC terá problemas em trabalhar com um código colaborativo ou legado.

Não há plugin de validação de código

Esta é uma meia verdade. Existe uma opção no Web Developer para exibição da validação da página que cobre o HTML5. O problema é navegar em outras páginas durante o trabalho. Tudo fica extremamente lento. E também há este plugin para Firefox que joga para o html5.validator.nu, o que é totalmente inútil se você estiver trabalhando localmente. E se você estiver com algum tempo livre sobrando, pode também instalar o validator.nu no seu ambiente local e usar o plugin do 456 Berea Street. Não tenho uma teoria de o porquê de não termos um bom plugin para validação ainda.

É de verdade ou é de brincadeirinha?

Qualquer aplicação ou site já desenvolvido pode ser passado integralmente para HTML5 sem dano. Basta mudar declaração do tipo de documento e validar a página para corrigir alguns detalhes. Mas o ideal é verificar quais são as novas tags disponíveis para a organização de um documento e treinar novas aplicações em diversos tipos de documento. Aqui vale um estudo mais cuidadoso dos modelos de conteúdo (ou content models). Aí está algo que nunca demos muita importância no passado principalmente depois das “verdades absolutas” proclamadas pelos evangelistas de SEO sobre o peso de cada elemento dentro de um documento e a relevância destes conteúdos para os mecanismos de busca.

E funciona no Internet Explorer?

Sim, HTML5 funciona no Internet Explorer com um JavaScript para habilitar as tags específicas. Mas não se preocupe: HTML5 está nos planos da Microsoft para o IE 10. Veja mais sobre este script no HTML5 Doctor.

De qualquer forma…

Todo desenvolvedor deve aprender HTML5. Nunca sabemos quando será o próximo projeto e quais serão seus requisitos básicos. E esta nova especificação não é difícil. Tenha em mente apenas que a semântica está mais presente e tem um papel mais fundamental do que nas versões anteriores. E este sempre foi o calcanhar de Aquiles do desenvolvimento para a Web.

Lembre-se sempre: HTML5 é mais do que as maravilhosas tags que permitem conteúdo rico em dispositivos móveis da Apple. ;)

Veja mais sobre este assunto:

• Uma outra visão sobre este assunto no artigo The HTML5 swich de Ben Buchanan
• Um texto do auge da euforia no LifeHacker: How HTML5 Will Change the Way You Use the Web, por Kevin Purdy

Aprenda HTML5:

• Tutorial de HTML5 do W3Schools
• O básico sobre as novas tags do HTML5 no Nettuts+
• Livro HTML5 for designers, de Jeremy Keith. Gosto muito da seção sobre content models.
• Coleção de links de artigos, tutoriais e demos de HTML5

E você tem alguma consideração sobre o desenvolvimento em HTML5?

Artigos relacionados:

• O progresso feito na marra
• Definindo estrutura, apresentação e comportamento
• Desenvolvendo de acordo com os padrões Web
• Visie: Code Show
• Acessível para quem?

E sem querer, Internet Explorer 6 morreu mesmo em março. Não o navegador que nos assombra, mas a relevância sobre compatibilidade entre navegadores. Ainda ouviremos reclamações sobre a morte do Flash Player, mas isso logo será passado também. Hoje o foco de nossas preocupações deve estar no futuro dos websites como referência de serviços online.

Estamos caminhando para a Web ubíqua, com aplicativos e dispositivos de todos os tamanhos e propósitos.

Em certos casos, o navegador não é mais o recurso primário de uso de um serviço na internet. O Gowalla, um aplicativo de geolocalização concorrente do Foursquare, existe somente como aplicativo para iPhone e Android. O site serve apenas para suporte e ajuda. Mesmo que você possua algum outro celular com navegador, não será possível usá-lo através da versão mobile do site.

Além disso, a vida sedentária que os desktops nos forçou a ter também acabará algum dia. Empresas brasileiras mais ágeis já devem estar planejando ou implementando a substituição de pesados computadores para notebooks e wi-fi, aproveitando a queda do preço do hardware nos últimos anos. Lá fora, não sei se já estão pensando fornecer iPads para funcionários. Preso num aeroporto durante o caos aéreo na Europa, o primeiro-ministro da Noruega foi capaz de governar o país através de um iPad.

O que muda para nós, profissionais da Web?

Muda tudo. No final das contas, é a velha briga dos padrões abertos repaginada. E como toda guerra, precisamos ficar bem informados sobre as tendências e devemos traçar estratégias.

Hoje temos um mercado de sistemas operacionais para dispositivos móveis dividido entre iPhone OS e Android. Mal dividido aliás, pois o hype sobre iPhones, iPads e afins gerou uma enorme demanda por aplicativos para estas plataformas, principalmente entre os editores de conteúdo tradicional, como revistas e jornais do mundo físico. A esperança de não termos um monopólio de plataformas está na estratégia do Google em manter o código aberto no Android e também no Google Tablet.

Se você questionar se não é melhor logo a Apple manter este monopólio, podemos conversar sobre como o IE6, mencionado anteriormente, atrasou a evolução da Web nos últimos anos.

Mais sobre isso:

• O título deste artigo é diretamente inspirado no artigo do The Next Web que traz outros exemplos de como estamos cada vez mais atraídos pelos aplicativos.
• Mas o conteúdo veio de uma série de twitts que publiquei semana passada depois de ler este artigo sobre as novas demandas dos usuários.
• E este post também é uma continuação de “O progresso feito na marra“.
• Um cálculo: o HTML5 pode levar mais doze anos para ser completamente desenvolvido.
• No Mashable: Hospital Outfits Staff with 100 iPads.
• Na Wired: The Web Is Dead. Long Live the Internet.

Artigos relacionados:

• O progresso feito na marra
• A informação ubíqua
• Sendo pago apenas para estar lá
• Desenvolvendo de acordo com os padrões Web
• Latitude, Longitude: A geolocalização na Web 2.0

A  matéria de capa do Jornal do Brasil de hoje é sobre a compra num clique da Saraiva e do Submarino. Segundo o jornal, a nova ferramenta destes sites de comércio eletrônico permite uma compra super rápida com dados de forma de pagamento e endereço de entrega pré-cadastrados pelo cliente. Isso é ótimo para quem tem metas a cumprir, mas imagino o pesadelo que deve ser para o atendimento ao consumidor devido a erros nos pedidos.

A experiência de comprar na internet passa pelo impulso sim, mas também precisa ser um evento especial para o cliente. Comprar nestas lojas não pode ser trivial como compras de mês no supermercado. Deve ser valorizado, acalentado e, principalmente, realizado com cuidado. Uma compra errada de um livro é bem mais traumática do que a de um amaciante de roupas, mesmo que o valor seja igual. E não há nada mais desagradável do que depois de realizado um pedido numa loja, ter que ligar e alterar a forma de pagamento ou o endereço de entrega.

Não fiz uma compra de teste nestas lojas porque, confesso, fiquei com medo de acabar fazendo um pedido teste e chegar algo lá em casa. :) Se você fez o teste, conte-me como foi.

A extrema facilidade não pode ser confundida com persuasão. Todo o processo de compra deve ser cuidadoso, confirmando junto ao usuário sobre cada informação fornecida. Erros que podem ser evitados no momento da compra significam menores custos no atendimento posterior e um impacto negativo menor nas mídias sociais.

Artigos relacionados:

• A crise e o e-commerce 2.0
• A identidade virtual da pessoa jurídica
• A realidade paralela dos fakes no Twitter
• Incentivando a colaboração do usuário
• Banheiros modernos

Nas últimas semanas, lovemarks de tecnologia andam anunciando produtos e serviços que entram em conflitos com outras marcas:

1. YouTube lança uma versão HTML5 do site que dispensa o uso do plugin Flash Player (via Mashable). O player ainda funciona em poucas versões de navegadores e tem alguns bugs, mas já funciona.
2. Apple anuncia o iPad que, assim como iPhone e o iPod Touch, não possui suporte ao Flash. Dias depois, Steve Jobs afirma em entrevista que a Adobe é uma empresa preguiçosa. Não sem razão. A versão do Flash para MacOsX causa mais travamentos do que na do Windows.
3. Google suspende o suporte ao Microsoft Internet Explorer 6 (no Computerworld), A medida também vale para Firefox 2, Safari 2 e Chrome 3. A isso se junta a campanha forte nos últimos meses para matar o IE6 liderada pela própria Microsoft. Não sabemos o estrago que as estações de trabalho que ainda rodam XP por causa disso estão fazendo às vendas do Windows 7. Além disso, governos europeus passaram recomendar o uso de navegadores alternativos depois da invasão de contas de ativistas chineses graças a uma brecha de segurança no IE.

A Web vive de ondas rápidas. Muitos poucos sites conseguem fidelização de seus usuários que duram anos. A exceção são os serviços – como provedores de acesso e de webmail – e os portais que provém este serviço. Nos últimos anos, algumas redes sociais conseguiram isso com sucesso em alguns mercados, como o Orkut no Brasil e o Friendster nas Filipinas.

O irônico, é que a plataforma que sustenta este mercado volátil é praticamente o mesmo há dez anos. Fora algumas iniciativas da comunidades, como a adoção maciça do CSS para estrutura e dos frameworks JS, não houve evolução significativa no desenvolvimento para a Web.

Em desenvolvimento server-side, o mercado se dividiu entre Java, Microsoft .Net e PHP. Alguns desenvolvedores tem migrado para Ruby, outra linguagem dos idos de 1990. Para aplicações ricas, temos o Adobe Flash, que domina o mercado desde 1996, apesar de outras iniciativas como o Silverlight. Além disso, o Flash Player está instalado em 99% dos computadores, sendo uma alternativa mais viável para a publicação de vídeos em sites como o YouTube e o Vimeo e matando o mercado do Quicktime, do Real Player e do Windows Media Player.

O HTML5, juntamente com o CSS 3, é uma especificação ansiosamente aguardada pelos desenvolvedores por causa dos seus inúmeros recursos, mas também é uma demanda das empresas de vanguarda. A nova fronteira é móvel, onde MacOsX e Android evoluem rapidamente para se manter competitivas. Veja este vídeo sobre o Motorola Milestone, onde a plataforma de desenvolvimento se tornou um argumento de venda.

O que vem por aí é excitante. Todos sabem disso. E se for necessário bater forte em um adversário, Apple e Google não se intimidarão. Para nós, profissionais da Web, tudo o que resta é se manter atualizado com as boas práticas e com as novas especificações mantendo os dois pés bem firmes na terra.

Leia mais:

• iPad e Google empurram migração para HTML 5, Raphael Monteiro Barboza no Webinsider;
• Nova linguagem de internet promete ser o futuro da navegação, eBand;
• Empresa aérea bane Flash de seu site, IDGNow;
• 7 Reasons For Apple To Acquire Adobe, The Next Web;
• Como Adobe e Google estão garantindo que o Flash jamais morrerá, no iMasters;
• Declaração de Steve Jobs sobre o Flash.

Artigos relacionados:

• A morte dos sites
• O que você precisa saber sobre HTML5
• Desenvolvendo de acordo com os padrões Web
• A informação ubíqua
• Definindo estrutura, apresentação e comportamento