Adicionando um pouco de contexto, o foco deste post é conversar sobre duas formas de trabalhar em ambientes que envolvam UX no desenvolvimento de projetos Web:

Quando pensamos com mais calma sobre estas comparações, acho que a conclusão fica meio óbvia, principalmente se o objetivo é ter a melhor qualidade possível como “saída” do nosso trabalho. Explicando: ao desenvolvermos um projeto novo o que é mais fácil? Fazer pequenas partes muito bem, com foco total e com o decorrer do tempo ir desenvolvendo as outras partes enquanto se ve o software funcionando, OU fazer um grande projeto com milhões de partes de uma só vez, para depois de um tempo razoável entregar todas as telas e suas variações para a próxima área responsável? É importante lembrar que em times ágeis o que é definido como entrega é software funcionando e não um monte de telas, especificações, casos de uso ou documentações.

Fazendo um paralelo com o nosso dia a dia (pelo menos eu sou assim), quando tentamos fazer muitas coisas ao mesmo tempo, geralmente não fazemos nada com profundidade e no final acaba tudo ficando “meia boca”. Ao ir desenvolvendo novas funcionalidades ou melhorias a cada 15 dias (citando um exemplo da duração de um Sprint aqui no Yahoo!), podemos pensar bem a respeito do funcionamento de cada item e, mais importante, temos a chance de envolver todos no time nas decisões: desenvolvedores, designers, Produto, QA, etc. Com isso eu sinceramente acredito que a qualidade geral do produto e das decisões tomadas aumentam exponencialmente e ficam cada vez mais consistentes com o tempo.

Sempre que vi um projeto sendo feito da forma tradicional, existia um batalhão de Designers que faziam “milhões” de telas, para que todas as variações possíveis fossem mapeadas antes de serem entregues para a equipe de desenvolvimento, muitas vezes chamavamos estas pessoas de “replicadores de telas”. É óbvio que quando se faz um trabalho em massa, como se fosse uma fábrica, nem tudo terá a melhor solução e alguns parafusos deverão ser apertados mais tarde, algumas partes vão precisar de alguns remendos para encaixarem e com certeza várias das telas criadas nunca serão implementadas representando total perda de tempo e dinheiro. O mesmo acontece com as fábricas de software, elas fazem com que os desenvolvedores trabalhem em paralelo como se cada um fosse uma máquina (os famosos Code monkeys). Os designers “Replicadores de telas”, nada mais são do que uma versão da fábrica de software aplicada ao UX.

Estes são conceitos bem básicos sobre desenvolvimento ágil e que podem ser melhor visualizados através das duas figuras abaixo:

Figura 1: Sprints com entregas constantes

Na Figura 1, temos o modelo ágil onde ao final de cada Sprint sempre haverá uma entrega de software funcionando, ou seja, com entrega de valor para o cliente, valor perceptível e paupável, pois estes poderão ver seu produto funcionando e se tornando real de forma evolutiva. Uma situação interessante é que se o orçamento acabar no Sprint 3, pelo menos o produto terá 3 Sprints completos de funcionalidades entregues e funcionando em produção.

Figura 2: Metodologia Waterfall

Na Figura 2, temos o método tradicional, onde vemos que o produto só vai funcionar ao final de quase todas as etapas, o que pode levar a tomadas de decisão preciptadas. Aplicando a mesma situação, se o orçamento acabar na fase 2 (Arq. da Informação e Design) o que podemos entregar para o cliente é uma série de documentos e PSDs, nada de software funcionando.

Failblog.org

Micro-blogging: Como muitos já escreveram por aí, em 2009 o Twitter terá de se concentrar em achar um business model sem deixar de crescer sua audiência. No Brasil acredito que o Twitter já atingiu todos os early adopters e será difícil ele avançar para as massas muito além do crescimento orgânico do mercado, mas Micro-blogging veio para ficar e em 2009 vamos ver mais consolidação neste mercado. O Orkut deve lançar alguma funcionalidade que facilite o micro-blogging e a conversação assíncrona das pessoas nos meus diversos grupos de amizade.

Comunidades: Orkut continuará imbatível e gigantesco, acho que a plataforma de apps vai evoluir no segundo semestre, meio que seguindo a tendência ditada pelo Facebook que já tornou os seus apps algo secundário (em uma aba separada chamada Boxes). Haverá a grande briga para definir quem será o grande mantenedor da identidade digital (personas) dos usuários. Já não faz sentido sites e aplicações terem de criar – e manter -  seus social graphs do zero quando os próprios usuários já elegeram onde mantêm atualizados seus dados e conexões. De qq forma é um mercado bem grande e ser o número 2, atrás do Orkut, não é nada mal. Mundialmente Google, Facebook e, correndo por fora, MySpace brigarão para que suas plataformas se tornem o padrão do mercado. No Brasil, Google já sai com alguns milhões de corpos de frente e o Friend Connect deverá se tornar o padrão por aqui.

Agregadores e LifeStreaming: Em 2008 vimos surgir um grande número de serviços agregadores, ou LifeStreaming, outros se consolidaram como FriendFeed, SocialThing e alguns se foram como o Pownce (deprecated), entre outros. O foco destes serviços em 2008 foi o de agregar o máximo possível de serviços e sites, ênfase total no volume. Com isso temos mais do que nunca uma sobrecarga de informações sobre todas as atividades que todas as nossas conexões fazem, é impraticável. Em 2009 vamos ver muitos novos agregadores surgirem, mas acho que os Players já estabelecidos deverão investir em algoritmos que façam com que o consumo do LifeStream das nossas conexões, seja mais relevante. Aposto que o FriendFeed será o grande destaque neste front.

Metodologias ágeis: Continuaremos a ver as metodologias ágeis se espalharem pelo Brasil com mais e mais cursos e certificados em metodologias como o Scrum, e devido ao fato de estas práticas se tornarem cada vez mais populares, vamos ter um fenômeno onde várias empresas vão fazer muita besteira e  vão dizer que essas coisas de Post-its e Self Organization não funcionam, voltando para suas práticas convencionais e muito buzz vai surgir de que é o fim das metodologias ágeis, como já aconteceu em 2008. Tb vamos ver várias empresas tendo sucesso na implementação destas metodologias e com isso mais e mais material e cases vão surgir, e espero que não só no mundo de desenvolvimento Internet. É importante mencionar que vamos ter o primeiro Scrum Gathering acontendo no Brasil em 2009 e que promete trazer grandes nomes do Movimento Ágil, como Mike Cohn e Ken Schwaber. Tb acho que apesar dos esforços da comunidade não teremos muitos avanços na integração de metodologias ágeis com UX (ou experiência do usuário), ainda existem grandes barreiras culturais que segregam os profissionais de UX dos de Desenvolvimento e Engenharia. Acho que isso esta longe de se resolver, e é sem dúvida um assunto super interessante que vou acompanhar em 2009.

Celulares: Nenhuma novidade para 2009, tudo será a mesma coisa, pelo menos no Brasil, onde a maioria das pessoas faz somente chamadas de voz e no máximo manda SMS. Download de apps e software continuará sendo nicho do nicho e Internet de verdade continuará restrita ao iPhone, que por sua vez vai continuar nichado e caro.

Portais: Os portais devem começar a fazer mais personalização, se tornando “canvas” para aplicações OpenSocial, assim as apps feitas para o Orkut poderão ser tb instaladas na Globo.com, Yahoo! e outros portais. Nos mesmos moldes do que o LinkedIn e outros players estão fazendo nos Estados Unidos.

Advertising: A grana de propaganda será curta este ano e o mercado de Internet vai sentir, Google continuará o grande líder no mercado e devemos ver alguma consolidação em display nos EUA, mas no Brasil continuaremos na maior “zona”, talvez alguma Ad Exchange Network venha para cá, trazendo algum respiro de novidade para o mercado.

Video Technology: Adobe continuará nadando de braçada nesta área e o Flash Video se tornará cada vez mais agnóstico e estará presente em praticamente qq device com poder de tocar vídeo e se conectar na Internet (menos o iPhone). A Micro$oft deve continuar investindo no Silverlight, mas ela já percebeu que o jogo será muito mais difícil e de longo prazo, de qq forma como dinheiro não é um problema para a M$, ela deve anunciar uma versão mais madura do Silverlight na NAB2009, com melhores ferramentas de autoria. Sendo assim, não veremos concorrentes que incomodem a Adobe em 2009.

Acho que esta bom para uma primeira tentativa. Aqui tb tem algumas outras previsões, do John Battelle , Kara Swisher e Jason Calacanis.

Agilidade envolvendo Experiencia do Usuário, ou simplesmente UX, é um dos assuntos mais quentes no “mundo ágil” nos últimos tempos, como fazer para integrar o desenvolvimento de software com a Experiência do Usuário e Design. O Jakob Nielsen fez um ótimo post a respeito (com um viés um pouco “nós contra eles”) com direito a um post resposta bem legal do Alistair Cockburn. E alguns dias atrás o Guilherme Chapiewski fez um excelente post sobre como tem sido a experiência na Globo.com até o momento. Eu passei por este problema lá e quando vim para o Yahoo! resolvi tentar um novo “approach”, que na verdade era o que eu sempre quis fazer na Globo.com.

A primeira diferença que notei é que no Yahoo! não existem as diversas camadas de responsabilidades na parte de Interface/UX/Design. Na Globo.com existem três camadas que são responsáveis pelo visual e UX de um projeto: Os designers, os Arquitetos da Informação e os desenvolvedores Client Side. Claro que os problemas são muito amenizados quando estes três profissionais são alocados no mesmo time ágil. Mas agora olhando de fora, eu sinceramente acho que isso não resolve o problema.

No final o problema principal é a comunicação, como todos sabemos e já foi mencionado por Jack Welch (veja o quote abaixo) quanto mais camadas vc tiver pior será a comunicação, maior será a burocracia e principalmente o comprometimento com o produto final, podendo gerar os mini-waterfalls.

The more layers in a business, the more spin, meddling, and worst of all, delays

Quando estava formando meu time no Y! uma das principais premissas era não criar silos de especialização, ou seja, ter desenvolvedores que queiram mexer com todo o ciclo de desenvolvimento desde BackEnd, Banco de dados até Frameworks Javascript e TDD; um Product Owner que queira entender a importância dos desenvolvimentos de infra-estrutura e processos de qualidade e, neste mesmo contexto, eu tb estava procurando um Designer que não tivesse medo que meter a mão em código e desenvolver a parte Client Side quando fosse necessário. A primeira parte não foi tão difícil, existem muitos desenvolvedores multifuncionais e que tem a cabeça aberta para assimilar que eles devem entender de todo o ciclo e não apenas de uma ou outra parte. Mas achar um Designer/UX que também entenda de implementação não é nada fácil. Apesar de que todos os Designers que conheço (ou quase todos) fazem “freelas” que envolvem escrever código e muitas vezes desenvolvimento usando PHP ou Ruby, quando estão trabalhando na empresa muitos deles se limitam a gerar um PSD, muitas vezes não porque queiram, mas devido a forma como o processo foi estruturado.

No meu time atual tive a sorte (e bota sorte nisso) de encontrar um Designer que gosta de desenvolver toda a experiência, e tem a função de garantir que a visão de funcionamento e design do produto esta sendo bem executada do início ao fim. Neste caso o Designer ou UED (User Experience Designer) tem a responsabilidade de criar a experiência usando sua ferramenta favorita (Fireworks no caso) e depois implementar este design em código garantindo que tanto o visual quanto a experiência será a mesma em todos os browsers que suportamos e de que as boas práticas de implementação estão sendo seguidas.

O que sempre ouvi dizer é que não é possível fazer a interface/design sem pensar no produto todo, na experiência que estou tendo nesse momento posso dizer que isso é meia verdade. A visão do produto precisa estar clara: o que é o produto, quais as funcionalidades chave, qual o público que ele se destina, etc. Mas estou podendo constatar que não é preciso ter todos os detalhes para desenhar a experiência, e que sim podemos fazer a implementação da experiência aos poucos junto com a evolução do produto. No nosso caso estamos apenas no segundo Sprint e o desenvolvimento da interface/design e UX estão seguindo as histórias priorizadas no Backlog, e é muito legal ver a interface ganhando forma de uma maneira iterativa, posso dizer que a interface do nosso protótipo mudou umas 10 vezes (totalmente) e isso em nada impactou os desenvolvedores.

Isso acontece porque decidimos separar totalmente a “camada de apresentação” da “camada de negócios”, o UED é responsável pela camada de apresentação codificando e comitando os templates Django diretamente no SVN. Com isso o UED tem total controle da interface e pode alterar totalmente a usabilidade sem necessitar de outras pessoas (camadas) para isso.

Na última semana, foi até engraçado, pois estavamos todos trabalhando com uma interface na cabeça e de um dia para o outro o UED do time mudou totalmente o funcionamento da interface – para melhor claro. Neste momento me lembrei de como seria se tivessemos as três camadas envolvidas (designer, arquiteto, clientside) … acho que levaria alguns dias/semanas para discutir tudo e no final provavelmente a interface seria vetada por se tratar de uma mudança muito radical. Neste ponto vale lembrar que não adianta ter pessoas de qualidade se vc não deixar que elas tomem decisões, neste caso quem possui a última palavra em termos de UX é o nosso UED.

Voltando aos principios ágeis, onde pensamos iterativamente, sempre entregando software funcionando a cada sprint, posso dizer que se fossemos utilizar a forma antiga onde o UED investe 20 dias (no mínimo) pensando em todos os fluxos possíveis do produto, mais a identidade visual, mais toda a teoria. Com certeza hoje estariamos jogando grande parte deste trabalho fora, pois a idéia do funcionamento do produto evoluiu muito nos últimos 15 dias, e ao incluirmos evoluções iterativas do design/UX conseguimos fazer os ajustes necessários e o impacto foi mínimo. Claro que estou contando com possíveis grandes alterações no futuro, mas pelo menos estas alterações serão fruto da visualização do design aplicado na prática e não de um monte de PSDs e Fluxos de arquitetura.

Ainda não sei o quanto esta forma de trabalhar vai escalar no futuro, mas o ganho que tivemos na agilidade e na qualidade neste início estão valendo a pena.

A primeira impressão é de que tudo é grande, realmente grande, os projetos de infra-estrutura são projetados para suportar volumes imensos de acessos. Mas uma coisa que impressiona, apesar de nao ser novidade é a extensão do uso de softwares Open Source, desde o óbvio como Linux, FreeBSD, Apache e MySQL até o Asterisk, XMPP e Twiki, este último suporta toda a documentação da empresa mundialmente, e o melhor é que todos usam o Twiki, pessoal de Marketing, Engenharia, Produção, etc. Em algumas empresas as pessoas acham um absurdo se sujeitarem a escrever no Twiki, mas no Yahoo! todo mundo usa.

Outra coisa nova para mim é a questão da distância entre os times, aqui alguns projetos são tocados por times em vários países e algumas vezes em continentes diferentes. Para suportar este ambiente uma série de tecnologias são usadas, mas a que achei mais legal foi o Adobe Connect – pena que não é Open Source, as apresentações e treinamentos acontecem através desta ferramenta e é bem legal, realmente funciona. Mas ainda acho que a distância é um fator importante durante o desenvolvimento de software.

É importante também lembrar que estes últimos anos o Yahoo! iniciou um processo de abertura de sua infra-estrutura, seus dados e suas propriedades para que desenvolvedores possam criar em cima de seu Social Graph e de produtos. Isso vem ocasionando uma série de mudanças internas e de desenvolvimento para suportar esta abertura e tornar o Yahoo! o ponto de partida dos internautas. Esta iniciativa é conhecida como Yahoo Open Strategy ou Y!OS, e as primeiras entregas começaram a ser disponibilizadas recentemente como o o BOSS (Build Your Own Search) que expõe todo index do Yahoo para que qq desenvolvedor faça o que desejar com os resultados, SeachMonkey para criar novas formas de enriquecer os resultados de busca, Social Directory, Contacts/Address Book, Updates, fora todas as outras APIs que continuam disponíveis como Flickr, Delicious, Upcoming, GeoPlanet, YUI, etc. De tudo isso o que acho mais legal é o YQL (Yahoo Query Language), feito pela mesma equipe que criou o Yahoo! Pipes, esta ferramenta vai possibilitar que o Yahoo! seja um grande banco de dados que poderá ser consultado facilmente usando um padrão de queries muito parecido com SQL, muito legal.

Enfim, existem muitas coisas novas e vou continuar postando a respeito, até agora as primeiras impressões são positivas, apesar do momento de pressão pelo qual a empresa vem passando

PS: este post foi quase totalmente escrito através do iPhone com o WordPress app.

Para começar a usar, primeiro instale a Extension no seu FF3 e depois Subscribe o script no seguinte [link]

Para saber mais sobre esta ferramenta fantástica e desenvolver seus scripts dê uma olhada aqui e aqui tem uma lista de comandos que vc pode adicionar ao seu Ubiquity.

O vídeo abaixo tem uma demonstração feita pelo Aza Raskin, do que é a primeira versão do Ubiquity, é realmente inovador e MUITO ANIMAL. A idéia não é nova e existem váriso aplicativos que ajudam a fazer estas coisas no Desktop, como o QuickSilver no caso do MacOS e o GNOME Do no Linux. É nestas horas que vemos como a Microsoft esta ferrada neste front de browsers e experiência, tudo o que ela esta fazendo de novo no IE8 são Activities e WebSlices e correndo atrás de adotar os padrões W3C.

O oEmbed é muito simples e a idéia é interessante, ao invés de vc ter de aprender as mil APIs dos diversos sites que existem na Internet para poder “embeddar” conteúdos destes sites, como Facebook, Orkut, Flickr, Picasa, etc. Vc pode usar a interface oEmbed dos seus providers favoritos, a promessa é que o oEmbed faça para as midias mais complexas (vídeo, áudio e fotos) o que o RSS fez para os conteúdos em texto.

Aqui segue um exemplo:

http://www.flickr.com/services/oembed/?url=http://www.flickr.com/photos/acarlos1000/2314303384/

A Resposta é:

{
"version": "1.0",
"type": "photo",
"width": 500,
"height": 281,
"title": "GloboVideos no MacBook e no Nokia N810",
"url": "http://farm4.static.flickr.com/3231/2314303384_c965ef5c96.jpg",
"author_name": "Acarlos1000",
"author_url": "http://www.flickr.com/photos/acarlos1000/",
"provider_name": "Flickr",
"provider_url": "http://www.flickr.com/"
}


Só acho que é meio nebulosa esta questão de ter a “oEmbed API”(API EndPoint) e uma URL para o Request, quando na verdade isso tudo vai gerar um request HTTP GET e poderiamos implementar isso com REST sem precisar passar por nenhuma “API”. Mas porque simplificar se podemos adicionar algumas camadas de burocracia.

De qq forma esta iniciativa esta apenas no início e com certeza vai evoluir bastante, alguns nomes de peso da Web estão implementando suas APIs oEmbed logo abaixo esta uma lista destes Providers:

Flickr (http://www.flickr.com/)

• URL scheme: http://*.flickr.com/*
• API endpoint: http://www.flickr.com/services/oembed/
• Example: http://flickr.com/services/oembed?url=http%3A//flickr.com/photos/bees/2362225867/

Viddler (http://www.viddler.com/)

• URL scheme: http://*.viddler.com/*
• API endpoint: http://lab.viddler.com/services/oembed/
• Documentation: http://wiki.developers.viddler.com/index.php/OEMBED
• Example: http://lab.viddler.com/services/oembed/?url=http%3A//www.viddler.com/explore/cdevroe/videos/424/

Qik (http://qik.com/)

• URL scheme (videos): http://qik.com/video/*
• URL scheme (user channels): http://qik.com/*
• API endpoint: http://qik.com/api/oembed.{format}
• Example: http://qik.com/api/oembed.xml?url=http%3A//qik.com/video/49565

Pownce (http://pownce.com/)

• URL scheme: http://*.pownce.com/*
• API endpoint: http://api.pownce.com/2.1/oembed.{format}
• Example: http://api.pownce.com/2.1/oembed.xml?url=http%3A//pownce.com/mmalone/notes/1756545/

Revision3 (http://revision3.com/)

• URL scheme: http://*.revision3.com/*
• API endpoint: http://revision3.com/api/oembed/
• Example: http://revision3.com/api/oembed/?url=http%3A//revision3.com/diggnation/2008-04-17xsanned/&format=xml

Hulu (http://www.hulu.com/)

• URL scheme: http://www.hulu.com/watch/*
• API endpoint: http://www.hulu.com/api/oembed.{format}
• Example: http://www.hulu.com/api/oembed.xml?url=http%3A//www.hulu.com/watch/20807/late-night-with-conan-obrien-wed-may-21-2008

Mais uma vez o Google dá um passo a frente e se coloca como ferramenta e não necessariamente como um site de relacionamento social como é o Orkut.

O @nandop fez um post bem legal com as primeiras impressões sobre o este novo serviço do Google, vale a leitura.

Nesta semana a Microsoft “walked away” e desistiu da oferta de comprar o Y!, isso nos faz pensar o que a Microsoft fará para deter o Google na sua expansão online. IMHO o que esta acontecendo com a Microsoft é que ela demorou a entender as novas possibilidades que surgiram com a Internet, na verdade a Microsoft nunca gostou da Internet ela apenas aceitou que isso existe e usou todo o seu poder ($$$) para destruir a Netscape e colocar o seu browser como a “única” opção, mas o que estamos vendo agora é que essa estratégia da MS que funcionou tantas vezes não esta mais funcionando, a empresa é lenta e tem um mindset antiguado, um mindset de desktop.

Ela parece viver em ciclos de 4 em 4 anos, e neste interim abandona seus produtos totalmente, vejam o que aconteceu com o Internet Explorer e com o Windows Media, no primeiro caso é nítida a lentidão com relação ao Firefox, uma das provas é que até agora não li nada de relevante sobre o IE8 a não ser que eles estão tentando ser mais compliants com os padrões W3C, tentando ser copliant agora?? Em 2008?? Pelo amor de Deus!!! O FF3 vai trazer algumas novidades bem legais, promete arrumar os leeks (let’s hope) e vai continuar pequeno 5 ou 6 MB, já o IE7 precisa de uns 100MB, imagina o que será o IE8.

No caso do Windows Media foi muito pior, a Adobe tomou o mercado de supetão e agora vai ser muito difícil e vai custar uma boa grana para a Microsoft se equiparar. O Silverlight esta MUITO longe do ecosistema que existe em torno do Flash, e vejam que não necessariamente estamos falando de soluções de código aberto, a Adobe é a empresa que mais odeia Open Source depois da MS.

Eu lembro de falar com alguns executivos da MS alguns anos atrás e alertar que o Windows Media estava ficando pra trás e que nós na Globo.com não teriamos opção e iriamos usar cedo ou tarde o Flash, a resposta foi no mínimo triste. Toda a empresa na época estava focada em terminar o Vista e o novo Office, todo o resto foi colocado de lado, incluindo ai o IE e o Windows Media, este foi o preço a se pagar.

Você pode notar que a Microsoft esta tomando uma surra em quase todos os segmentos, Windows Mobile 6.1 não mudou quase nada em relação ao que era a 3 anos atrás, nem o Messenger mobile a Microsoft consegue fazer direito, existem milhões de opções de desenvolvedores terceiros que são melhores e não vou nem perder tempo com o IE mobile, este simplesmente não existe.

Alguns de vcs talvez não saibam, pois não se falou muito deste produto no Brasil mas a MS tentou criar um concorrente para o YouTube que se chamava Soapbox, ela errou em todos os passos, primeiro com a velha mentalidade de usar o Windows Media como formato de vídeo, depois trocou o player para Flash, mas aí era tarde demais, hoje o SoapBox não passa de uma aba no MSN Video.

A Microsoft também não tem nada relevante com relação a comunidades, o Orkut impera no Brasil e Facebook e MySpace dominam o mercado americano, o Google fez um lance de mestre e lançou o Open Social enquanto isso o Live Spaces é irrelevante e talvez tenha o mesmo destino do Soapbox, virando uma aba no Hotmail talvez . Claro que nesta área de comunidades tudo pode se “resolver” com alguma aquisição, Facebook e MySpace são compráveis e estão dentro do alcance da empresa de Bill. Aliás a News Corp já deu sinais de que pretende se livrar do MySpace em breve.

A Microsoft também tentou entrar no mercado de MP3 Players com seu aparelho Zune, que já deve ter vendido em torno de 2MM de unidades, o que representa 4% de marketshare contra 71% do iPod, mas o produto apesar de ter evoluido razoavelmente nos últimos meses (lançou suporte a uma loja de vídeos nesta semana), ainda esta longe de ter o appeal e facinio que o iPod conquistou. Mais um exemplo da mentalidade ultrapassada da MS é que ao comprar músicas no Zune Marketplace vc paga em Microsoft Points, WTF? Por exemplo, um vídeo custa 160 Microsoft Points que é o equivalente a $1,99, pra que facilitar se vc pode complicar.

O Vista vende bem apesar de tudo, mas ele esta sendo adotado mais porque as pessoas não tem opção, e ao comprar um micro novo elas não podem escolher ficar com o XP, se houvesse esta opção, não tenho dúvida que o XP venderia mais. No mundo corporativo a história é diferente, as empresas estão evitando com todas as força migrar para Vista. Até a Amazon surpreendeu o mercado com seu Amazon Web Services, e Google e a própria Microsoft estão correndo para oferecer soluções de “Infrastructure as a Service” ainda este ano, o Google já deu o primeiro passo com o AppEngine e a SUN esta repensando os serviços que já oferecia em um projeto chamado Hydrazine.

Dado este cenário vemos porque a empresa de Seattle estava disposta a pagar tanto pelo Yahoo!, era uma opcão de colocar sangue novo na empresa, apesar de o Yahoo não ser nenhuma Brastemp em tempos de Googleplex e computação nas nuvens , mas o Yahoo ainda é o maior site do mundo em audiência e tem algumas propriedades interessantes como o Flickr, Del.icio.us, UpComing, OneSearch, Right Media, entre outros que ajudariam a incrementar o portfolio do Live.com

Além disso, tem toda a disputa pelo mercado publicitário online (a atual galinha dos ovos de ouro), que esta cada vez mais sob o controle do Google e começa a gerar o efeito Tostines, onde se você não tem audiência suficiente não há quem anuncie no seu site. Com a compra do Yahoo, a Microsoft iria ganhar escala e um grande volume de tráfego para suas ferramentas de advertising (MS AdCenter, Yahoo Publisher Network, Right Media, Maven, Yahoo AMP e aQuantive) criando assim algum tipo de resistência ao crescimento do Google.

Enfim, a empresa de Bill Gates tem uma dura empreitada pela frente, só que agora o seu principal concorrente tb tem dinheiro pra brincar, por outro lado a MS ainda tem uma posição privilegiada no mundo dos desktops. A questão é, por quanto tempo o desktop será relevante para as pessoas?

Mesmo que a maioria das empresas de TV nunca fechem em parceria com o Google para mostrar os Google TV Ads (porque não fazer isso para os horários da madrugada, por exemplo, pelo menos para testar), a interface e a facilidade de criar uma campanha apenas acessando algumas páginas através de um Browser é fantástica e acho que toda empresa de TV deveria tomar isso como exemplo e pensar em modernizar seus sistemas de atendimento as agências e parceiros comerciais.

Por enquanto, os comerciais do Google estão sendo veiculados em mais de 125 canais via Dish Network, segunda maior broadcaster via satélite dos Estados Unidos. Entre os primeiros a anunciar através da nova plataforma estão nomes de peso como Intel, E*trade, Financial Corp e 1-800-flowers.com Inc

Se vc trabalha em uma empresa de TV este video abaixo é um MUST HAVE.

http://www.google.com/adwords/tvads/

Simplesmente fantástico, mas concordo totalmente Merrill Brown, que foi Editor Chefe do MSNBC.com, quando ele diz que as empresas de mídia tem uma grande barreira quando o assunto é inovação e quando se fala de advertising a barreira é MUITO grande, imagine então quando se fala de advertising na TV.

Merrill comenta o caso do fracasso da startup Backfence.com, site especializado em hyperlocal news:

One of the big reasons why the startup failed is that it did not offer “self service” advertising tools that made it super easy for local companies to create and deploy ads. Instead, Backfence had to rely on a pre-1999 business model of sending a sales force door-to-door in the local communities that it served.

Sem comentários.