Tableless » Browsers

Google Chrome para Android

Diego Eis — Wed, 08 Feb 2012 13:05:08 +0000

O Google acaba de lançar o Google Chrome para Android. Antes que você fique todo alegre, o Chrome para Android só está disponível para os usuários do Ice Cream Sandwich ou tablets. Ele é baseado na simplicidade do Chrome para desktops, prometendo a experiência de navegação.

Eles reimaginaram o uso de tabs para os mobiles, e nas tablets a utilização as tavs ficaram similares com o Chrome para Desktops. Temos também incluído nessa versão mobile o famoso “Porn mode” ou o Incognito, que é o modo de navegação privativa.

O Google Chrome para Android ainda está em fase beta e você pode baixá-lo no MarketPlace mais próximo.

Uma boa notícia para toda a comunidade de desenvolvimento web mobile. A briga fica acirrada entre os sistemas. O que é bom para nós e para os usuários. Agora oremos para que o IE10 para Windows Phone saia logo, o que eu duvido. Acho que ele somente virá com o Windows Phone 8. Entretanto temos um ótimo cenário quando falamos sobre browsers para mobiles.

Posts Relacionados

Agora é a vez dos desenvolvedores

Diego Eis — Sun, 05 Feb 2012 13:53:11 +0000

O desenvolvimento web depende de três personagens principais: W3C, que regulamenta, cria e sanciona padrões para a web. Os browsers, que importam essas regras e padrões de forma que a web seja mais homogênea. E os desenvolvedores, que possibilitam a criação e publicação de conteúdo em vídeos, texto, imagem etc.

Cada um destes personagens tem papéis importantes para que a evolução da web possa se tornar forte, traçando novos caminhos, cobrindo as necessidades atuais dos usuários e prevendo necessidades e soluções futuras. Há um ciclo para que estes personagens possam cumprir com seus objetivos.

O W3C cuida dos padrões. Ele tem ideias, ele prevê problemas e tenta solucioná-los. O W3C não aplica, ele apenas planeja. É um trabalho difícil, por que é necessário uma visão muito apurada do cenário da web para saber quais caminhos ela deverá tomar. Uma decisão errada, pode acarretar problemas que levarão anos para serem solucionados por completo. Vide o desenvolvimento com tabelas. Por isso esse trabalho de planejamento deve ser meticuloso. Devo confessar que em muitos casos o W3C não supera as expectativas e faz com que iniciativas paralelas surjam e direcionem a Web para um caminha mais correto. Foi o que aconteceu com o HTML5.

Os browsers, por sua vez, precisam entender e adotar as idéias do W3C, absorvendo as soluções e criando suporte nos seus softwares. Esse trabalho também tem seus perigos. Os browsers precisam pesquisar quais das necessidades dos desenvolvedores é mais importante e assim implementá-la para que a utilização de projetos seja executada. Obviamente que alguns decidem suportar aquelas soluções que darão mais pontos estratégicos contra o concorrente.

Finalizando o ciclo, os desenvolvedores aplicam tudo o W3C define, mas apenas aquilo que os browsers “querem” ou podem suportar. E isso, claro, faz com que o desenvolvedor se depare com problemas na ponta produção. Vide o IE6/7/8 e nossos problemas de cada dia.

Durante muito tempo, esse ciclo não era afinado. Havia uma certa confusão e um jogo de interesses próprios envolvendo principalmente os browsers. O W3C estava apenas pensando em como resolver problemas que talvez existiriam daqui longos anos. Os browsers estavam apenas interessados em criar uma massa de usuários suficiente para ser o primeiro no ranking. Os desenvolvedores, por sua vez, queriam ganhar seu dinheirinho, fazer o trabalho, entregar pro cliente e acabar com o problema.
Ninguém deu atenção quando começamos a desenvolver com tabelas, fazendo com que os sites ficassem mais pesados, aumentando o tempo de desenvolvimento e o custo do projeto.

Este ciclo defeituoso foi praticado durante muito tempo. Por incrível que pareça, foram os Desenvolvedores que começaram a fazer o ciclo funcionar novamente como deveria. Eles acordaram os fabricantes de browsers e também o W3C.

O W3C passou a pensar mais em problemas presentes. Solucionou problemas iminentes e que entregavam valor para os projetos.

Os browsers suportaram o mais rápido possível essas mudanças, atualizando seus engines, e fortalecendo as bases para novas soluções e flexibilizações posteriores.

Já os desenvolvedores estagnaram. Desculpe-me, serei um pouco revoltado daqui para frente. Os desenvolvedores dormiram. Quando o W3C e os browsers apresentaram soluções para problemas como transparência, bordas arredondadas, backgrounds inteligentes, utilização de fonts remotas e etc, os desenvolvedores resolveram que não era a hora dessas soluções por causa da retrocompatibilidade com browsers antigos, como o IE6. Na verdade estou sendo meio injusto aqui. Não foram todos os desenvolvedores que criaram caso com a retrocompatibilidade, foram somente os idiotas.

Nós reclamávamos que precisávamos de recursos mais inteligentes para trabalhar. Que precisávamos de idéias realmente inovadoras, que transformassem os projetos e facilitassem o desenvolvimento. Protestamos, escrevemos manifestos, postamos em nossos blogs revoltados com a falta de visão do W3C e com a pobreza do suporte dos browsers. E quando conseguimos o que queríamos, demos para trás. Amarelamos. Pedimos arrego.

Infelizmente, via-se muito disso aqui no Brasil do que no resto do mundo. Ouvi muitas desculpas como: – “Mas meu cliente usa IE6.” ou “Mas isso não funciona em IE6.” Você é desenvolvedor. Você trata com seu cliente todos os dias. Você tem o poder de educar e convencer. E se você acha que não tem poder nenhum, por que ainda trabalha com web?

Talvez isso seja trauma do passado. Talvez não. O fato é que não podemos mais nivelar por baixo. Isso é atrasar uma “evolução” inteira.

Tenho incansavelmente falado sobre Graceful Degradation, Enhanced Progressive, HTML 5, as maravilhas do CSS 3 e etc, pois esse é o assunto que rola lá fora. Há desenvolvedores e empresas, que acham que devemos ter uma autorização especial dos gringos para utilizarmos novas tecnologias e principalmente para deixar os browsers antigos no passado.

Esse assunto me faz pensar em outra pergunta: Estamos (você está?) preparados para o ritmo alucinante do W3C e dos browsers?
Até a Microsoft está cumprindo com a palavra de ter um browser atualizado. Eles já anunciaram o novíssimo Internet Explorer 10, com uma série de atualizações que promete trazer o IE para o patamar de browsers atuais.

O mercado de client-side se transformará rapidamente nos próximos anos. Muitas mudanças no HTML e no CSS serão publicadas com o intuito de tornar a web mais homogênea, flexível, portável. O HTML 5 não é só uma coleção de novas tags e APIs. O CSS 3 não ganhou só bordas arredondadas. E nem só de iPhone vive o homem. Existem milhares de Nokias, Blackberrys, Windows Phones e Androids por aí.

Os desenvolvedores precisam acordar.

Artigo originalmente publicado em Nov/2009 na revista TI Digital.

Posts Relacionados

CSS1K

Diego Eis — Fri, 20 Jan 2012 10:56:42 +0000

Você deve conhecer o CSS Zen Garden. O CSS Zen Garden foi criado pelo Dave Shea, foi um dos sites responsáveis por convencer toda a galera desenvolvedora orgulhosa e desconfiada mostrando que era possível produzir e implementar websites flexívels, diferentes, não quadrados nem com cara de blog – como falavam – utilizando CSS puro. Tendo este pensamento em mente, Jacob Rask decidiu fazer o CSS1K: um desafio para você que acha que consegue implementar um design utilizando apenas 1K de CSS.

O que você tem que fazer é simples:
- Você só pode enviar CSS.
- O seu código CSS deve ter 1K (1024 bytes), minificado.
- Não precisa utilizar prefixos de browsers, eles colocarão lá para você, logo, você pode usar as coisas bacanas de CSS que só funcionam em browsers (não o IE).
- O Design não precisa ficar igualzinho em todos os browsers, mas gracefull degradation é uma boa pedida.
- Seu código é submetido sob a licensa MIT.

Eles dão o código HTML que você não pode modificar em hipótese alguma, se não acaba a graça da brincadeira.

E aí, consegue?

Posts Relacionados

Um pensamento sobre design para web

Diego Eis — Thu, 19 Jan 2012 10:20:37 +0000

É engraçado quando designers de peças offline tentam migrar para web e ficam assustados com as diferenças no processo de criação e produção. O controle que o design para impresso tem sobre a posição dos elementos e a forma final da arte nunca (nunca?) será a mesma na web. No impresso você define precisamente as medidas, posicionando dos elementos, o tamanho das letras, entrelinhas e cores (mesmo brigando bastante nas gráficas por aí). Já na web você briga porque um determinado elemento está deslocado para a direita em um browser ou outro, porque determinada fonte é maior em uma tela e até pouco tempo só tinha um punhado de fonts para criar. Mesmo quando definimos tudo em pixels, há variações inesperadas entre browsers e dispositivos. Também lembro quando havia muita diferença de cores de monitor para monitor. Graças a Deus temos monitores LCD/LED.
E agora ainda temos que prestar atenção aos dispositivos que comprimem mais pixels por ponto do que antigamente.

A boa experiência no design de impresso depende muito da arte inspiradora do designer, qual o papel usado, que tipo de impressão, da gráfica… em web dependemos muito do tamanho da tela, do dispositivo utilizado, do browser, da configuração do texto, velocidade da internet e do computador. São muitas variações para tentarmos manter o controle de cada detalhe.

Quando um designer faz peças para uma campanha ou algum projeto offline, dependendo do caso é necessário criar peças para diversos formatos de veiculação em outdoors, revistas, posters etc. Em relação a web, nós temos todos os formatos de telas que envolvem tablets, notebooks, monitores, TVs e celulares… Com um diferencial: cada uma dessas telas tem um tipo de comportamento diferente dependendo da manipulação do dispositivo e também do usuário. Em alguns dispositivos como tablets e mobiles em uma tela temos dois formatos: retrato e paisagem. Já no impresso não há manipulação pelo usuário. A estimulo é totalmente visual e muitas vezes tátil. Mesmo assim, a experiência que a web entrega é totalmente outra.

No design impresso, quanto mais proporcional, harmoniosa e equilibrada for a peça, melhor será recebida. No design para web também, mas os layouts precisam ser harmoniosos em cada um dos dispositivos, precisa ser proporcional em cada navegador, além da acessibilidade para alcançar usuário distantes.

Mas em ambas a personalidade é a plataforma para a emoção do usuário. Seja online ou offline, o layout, a forma com que o usuário o consome deve leva-lo para uma experiência diferente do normal. E não estou falando de hotsites feitos em flashs ordinários puramente comerciais.

Eu queria ser designer para entender melhor os conceitos que envolvem esse assunto e talvez explicar tudo isso com mais propriedade.

Assim como não é possível escrever uma linha de código sem saber os porquês da importância do código semântico e acessível, não é possível desenhar um website sem ter a plena certeza de que qualquer usuário terá uma experiência envolvente e agradável.

O design para web está mudando de novo outra vez por causa da explosão de novos dispositivos. Se você ainda não parou para pensar, pense: faça as contas das telas: notebooks, monitores, tablets e smartphones. Sendo que cada uma destes tipos de telas tem diversas variações de tamanho e principalmente de resoluções. Já disse que a experiência do usuário precisa ser cross-device, caso contrário, algo se perde.

Eu queria mesmo era fazer um carro.

Posts Relacionados

WebIntents – Framework para WebApps

Diego Eis — Fri, 06 Jan 2012 13:45:44 +0000

O Chrome e o Firefox estão trabalhando juntos em um framework open-source que fazem aplicações web trabalhem juntas sem que uma precise dar informações sobre seus respectivos sistemas. O nome deste framework é WebIntents.

O problema a ser resolvido é que se quisermos criar um sistema que utilize algumas facilidades de outros sistemas, nós precisamos aprender a API deste determinado sistema. Acontece que as APIs não são iguais. Se você quer utilizar um sistema de localização como Foursquare ou Gowalla, você precisa aprender como a API de cada um funciona e então escolher entre um dos dois ou utilizar os dois no seu sistema. Nesse caso, você tem o dobro do trabalho para manter seu sistema. Os dois podem modificar partes da sua API e você tem que ficar atento para que seu sistema não quebre. O WebIntents faz com que você consiga usar um comando para os dois serviços.

Web Intents, based on an existing capability in Google’s Android mobile OS, will let Web apps express a simple call for an action, like ‘share’ or ‘edit,’ which receiving apps will be designed to use, without either app needing to have specific knowledge of the APIs of the other. This way, instead of having to code for each specific Web app one might want to access, developers can just use these simple requests, which will be built into the browser. The Chrome and Firefox teams are each building this functionality for their own browser, but they’re combining their proposals to use a single API for Web app developers to reach both platforms.

Paul Kinlan, o dono da ideia e desenvolvedor do Google, explica no em um post no seu blog o que é o WebIntents:

“If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user.”

Não é de hoje que iniciativas de desenvolvedores e grandes empresas tomam forma para que o desenovlvimento web fique cada vez mais fácil e menos trabalhoso. Isso aconteceu com muitos grupos de desenvolvedores, como o pessoal da WaSP, o pessoal da WHATWG e mais uma vez agora com o pessoal do WebIntents. Claro, existem outras iniciativas anônimas que nos fizeram chegar até aqui.

Eu gosto muito muito de uma frase do pessoal da WaSP utiliza há tempos: If not now, when? If not you, who?

Veja aqui o GitHub do Framework.

Posts Relacionados

Utilizando APPs em vez de browsers

Diego Eis — Fri, 06 Jan 2012 11:00:35 +0000

De acordo com a comScore as pessoas estão usando mais mobile Apps para consumir conteúdo do que browsers.

O tráfego medido pela comScore mostra o market share dos principais players do mercado de mobile em Novembro. O Android continua ganhando, logo atrás vem o iPhone que foi impulsionado pelas vendas do 4S. Todas as outras plataformas perderam campo. Outra coisa, o report da comScore não conta com iPads nem iPods.

Os mobiles Android represetam algo em torno de 47% e o iPhone 30%.

O mais importante são os números abaixo que mostram o uso de conteúdo por estes dispositivos pelos usuários:

Acho que pouquíssimas pessoas, mesmo nos seus computadores, entram no site do Twitter para escrever em vez de usar algum App, não é verdade? Mesmo assim acho que o futuro não estão nos Apps. Eles sempre ficarão lá, firmes e fortes, mas aos poucos muitas empresas irão reformular seus sistemas web para ficar o mais parecido possível com as apps. Esse é o mais inteligente já que você não precisa reprogramar tudo novamente como é feito hoje. A mudança do CSS será o trabalho mais importante nesse caso, já que a interface “precisa” ser diferente em cada um aparelhos.
Na verdade não precisa… Mas é bom manter a interface nativa de cada um dos aparelhos para que os usuários não estranhem a utilização. Não seria bom que a interface do twitter no Windows Phone fosse igual a do iPhone ou a do Android. Confunde bastante. Não, é?

Só uma observação: estes números refletem a realidade lá dos states, ok? Provavelmente esse comportamento pode ser multiplicado em outros países, como aqui.

Posts Relacionados

Experiência cross-device

Diego Eis — Thu, 22 Dec 2011 05:20:40 +0000

Eu vivo comentando aqui no Tableless sobre o desenvolvimento de sistemas e websites para os diversos meios de acesso. Eu falei sobre esse assunto em diversos artigos. Eu li um artigo chamado The Coming Zombie Apocalypse, escrito por Scott Jenson em abril deste ano. Este artigo me fez perceber que eu estava levando o assunto muito superficialmente, mas que tem muito a ver com o artigo publicado aqui chamado A Experiência deve ter começo, meio e fim.

O artigo do Scott Jenson começa dizendo que a popularização dos smartphones são apenas o começo. Juntando o barateamento das peças para a produção destes aparelhos com a criação sistemas de baixo custo e acessíveis como o Android, não só estão surgindo dispositivos baratos capazes de fazer tarefas que antes eram possíveis apenas em computadores, mas dispositivos baratos baseados na web, trazendo uma experiência cross-device nunca antes experimentada. Um exemplo disso é quando utilizamos estes dispositivos integrados com aplicações como o sistema de som Sonos. O Scott Jenson chamada de Zombie Apocalypse dos eletrônicos.

O paradigma dos computadores desktops estão nos impedindo de enxergar novos caminhos não tão longes assim. Isso é totalmente evidente quando falamos sobre smartphones, no qual nós sabemos que não são computadores desktops e tão somente por isso nós temos outras experiências e outras abordargens quando estamos usando aparelhos deste tipo. Perceba que diversos serviços e aplicações estão sendo portados para os dispositivos móveis porque fazem mais sentido nesse meio. O Twitter mesmo foi criado inicialmente para publicações vindas apenas pelos smartphones. Foi um processo reverso.

Me lembro que aqui no Brasil o recebimento de SMS internacional era um problema em algumas operadoras. Muitos queriam utilizar o Twitter, mas não podiam atualizar suas timelines ou receber as atualizações dos seus colegas porque o Twitter, naquela época, era baseado em SMS. Foi aí que a plataforma se popularizou mais lá fora e então a possibilidade de atualizar sua timeline por outros meios surgiu.

Há uma frase interessantíssima no artigo de Scott Jenson onde ele diz assim:

This problem is simple, but pernicious: designers think of new technologies in terms of yesterday’s tasks, failing to clearly see the real potential of the new technologies.

Minha tradução livre: “O problema é simples mas pernicioso: os designers pensam nas novas tecnologias baseando-se nas tarefas de ontem, falhando em ver claramente o real potencial das novas tecnologias.”

Muito óbvio. É por isso que o Windows Mobile falhou! A Microsoft durante muito tempo liderou o mercado de sistemas para mobiles com um sistema ruim, bugado e muito, mas muito inútil, simplesmente porque eles eram praticamente os únicos. O problema com o sistema deles foi a tentiva de portar os conceitos, experiências, comportamentos e tarefas do sistema dos desktops para os mobiles. Claramente um grande erro. Com o Windows Phone eles mudaram (tarde) o cenário. Eles criaram o Windows Phone levando em consideração os atos e comportamentos do usuário em aparelhos deste tipo. Não há nenhuma analogia aos desktops. E mais uma vez, algo que foi criado primeiramente para aparelhos móveis será portado para os desktops, que é o caso da interface Metro levada para o Windows 8.

Os PCs de hoje serão apenas hubs num futuro próximo. No cenário de hoje você escolhe entre Mac ou PC e baixa aplicativos que muito provavelmente funcionarão apenas para um destes sistemas. O modelo ideal, que já é mais real do que imaginamos, é que cada pessoa possa usar múltiplos dispositivos acessando um mesmo dado, uma mesma informação, normalmente pela núvem.

O exemplo do serviço de música via streaming Pandora é perfeito. Ele permite que nós possamos utilizar seus serviços em uma variedade gigante de dispositivos. Sempre sincronizando suas músicas via internet. Tudo sempre integrado. Aqui no Brasil, como o Pandora não funciona, talvez não seja a sua realidade… Entretanto estamos vivendo em um mundo onde o software, a aplicação, o serviço, define qual aparelho você vai comprar.

O Sonos é um aparelho de som Wi-Fi. Além do Pandora você pode sincronizar sua biblioteca de músicas de diversos outros serviços como iTunes ou o Spotify. Quando o conheci eu o quis sem pensar. Nada de iPod ou iPhone plugado no aparelho de som. Nada de fio p2-p2 para ligar meu celular ao aparelho de som… Eu quero ouvir minhas músicas livremente pelo serviço que eu mais gosto no sistema de som da minha casa. Mas quando eu for pra rua e quero continuar ouvindo a mesma biblioteca de música, só que agora no meu fone de ouvido. Essa integração entre dispositivos e softwares é incrível. Perceba que não estamos falando sobre um ecosistema fechado como o da Apple. Estamos falando de hardware e software de fabricantes diferentes, que prestam diferentes serviços, mas que se integram.

Entende o que é a experiência do usuário nesse cenário?

Posts Relacionados

Command & Conquer: Tiberium Alliances

Diego Eis — Mon, 19 Dec 2011 13:29:23 +0000

Se você é fã de jogos de estratégia já deve conhecer o Command & Conquer. Para ser sincero eu não gostava muito dessa série e por isso joguei muito pouco. Achava tudo muito complicado.
Mas a notícia interessante é que a EA/Phenomic (os mesmos que desenvolvedoram de Lord of Ultima, BattleForge e Spellforce) vai lançar uma edição do jogo chamada Command & Conquer: Tiberium Alliances e vai ser baseado em HTML5.

Você poderá se unir com outros jogadores para formar alianças, criando impérios maiores e etc. Sendo em HTML5, você poderá acessar de qualquer browser. QUALQUER browser (viu, flash?). A EA também vai preparar as versões do jogo para mobiles facilitando a jogabilidade em dispositivos móveis (viu, flash?). Isso elimina aquele trabalho de criar uma versão para cada dispositivo e para cada plataforma. O custo vai lá para baixo! É exatamente por isso que eu sou contra APPs instaláveis nos aparelhos, principalmente móveis.

O custo de desenvolver um mesmo App para pelo menos a tríade dos sistemas móveis (Android, Windows Phone, iPhone) e depois para os sistemas para desktops (Apple, Windows e quem sabe Linux) é gigante. Não estamos falando só de sites, ok? Estamos falando de tudo, até jogos, como este da EA que está para sair. Se temos a possibilidade de fazer uma aplicação que pode ser usada em todas as plataformas com experiência relativamente igual, sem danificar gráficos, jogabilidade, velocidade e etc, porque perder tempo criando aplicações nativas diferentes?

Abaixo veja o trailer de como o jogo está ficando. Sensacional. Quero só ver quando WebGL puder ser usado de verdade nos navegadores.

Mais sobre o jogo. Eu vi essa notícia via @reinaldoferraz.

Posts Relacionados

O IE6 vai morrer no Brasil

Diego Eis — Fri, 16 Dec 2011 13:30:07 +0000

Ontem a Microsoft anunciou que em Janeiro vai ativar a atualização automática para os Internet Explorers dos sistemas Windows XP, Vista e Windows 7! E sabe por onde eles começarão a fazer esse milagre? No Brasil e na Austrália. Este é um passo importante para que a web, do mundo, avance mais rápido.

O mais interessante é a Microsoft está diferente. Ela realmente está colocando o usuário em primeiro lugar. Por exemplo: toda vez que o sistema atualizar a versão do IE, essa atualização não mudará a sua configuração de browser padrão, nem as configurações de buscador, bookmarks, nada. Isso faz parte da nova filosofia que a Microsoft tem adotado nos últimos tempos e que está dando muito certo.

Se consumidores e empresas não quiserem atualizar seus browsers, eles tem a opção de não fazer o update e continuar recebendo suporte para a versão do IE que eles ainda terão. Há também a possibilidade de desinstalar os updates caso seja necessário. Em versões mais avançadas do IE, a Microsoft colocará uma opção de desativar as atualizações automáticas.

Essa decisão é ótima para os consumidores, desenvolvedores e pricipalmente para as empresas. A Web ficará melhor e mais segura. Com esta decisão, nós, desenvolvedores, teremos um campo farto para novas oportunidades de entregar experiências melhores para nossos usuários. Com o IE9 já temos algumas features do HTML5 que funcinam. Nós iremos gastar menos tempo codificando para um browser específico, corrigindo erros e bugs. Isso quer dizer que sua obrigação de convencer e educar seu chefe e cliente fica bem mais fácil.

Você entende o que está acontecendo? Não é um grupo de desenvolvedores que resolveu tentar matar o IE e deixa a web livre… é a própria Microsoft. Você sabe o quanto isso é importante? Sério, pense nisso.
Eu sei que não faz mais que a obrigação dela já que foi ela que começou essa confusão toda, mas vamos lá… há quanto tempo estivemos esperando por uma decisão dessa?

Microsoft, obrigado!

Veja o post na íntegra no blog do IE.

E use este link para pegar a imagem do post em tamanho maior.

Posts Relacionados

Experiência deve ter começo, meio e fim

Diego Eis — Mon, 28 Nov 2011 23:55:31 +0000

Esse artigo pode parecer meio confuso, mas é apenas um pensamento que estive matutando. Não ligue se a ordem das ideias estiverem tortas e sinuosas.

Tive uma experiência muito ruim no primeiro dia de 2010: pulei na piscina com meu iPhone no bolso.
Ok, pode me xingar agora.

Depois da tragédia, ele durou rápidos 5 segundos, e faleceu. Não ligava, não apitava, não fazia nada. “Paciência”, falei para mim mesmo. No dia seguinte peguei um celular reserva que eu tinha guardado: um HTC Touch, com Windows Mobile 6 (não Windows Phone). Foi então que eu notei o porque o trabalho da Apple vicia os consumidores.

Estamos bem acostumados a utilizar um notebook ou um computador desktop, com monitor, teclado e mouse. A interface do sistema muitas vezes parece desaparecer quando se abre o navegador. A experiência de uso dos periféricos já é bastante conhecida e isso facilita muito a forma com que o usuário interaje com a interface. Há uma harmonia, se é que você me entende. A mesma coisa é dificil de acontecer quando utilizamos um dispositivo mobile. Em um dispositivo móvel você precisa de foco. Não há espaço para milhares de botões com dezenas de ações. É SIM e NÃO. É OK ou CANCELAR e mais nada. O que não é o caso do Windows Mobile. O Windows Mobile foi feito daquele jeito Microsoft. Muito, mas muito diferente do Windows Phone que está um primor. Com uma interface totalmente repensada, do zero, onde seu visual se integra com os outros sistemas da marca. Há uma homogeneidade na experiência do usuário quando ele usa a Live do XBOX, o Windows Phone e o Windows 8. A experiência é cross-platform. A Apple faz isso durante anos. E durante todos estes anos esse foi seu segredo. O famoso “eco sistema Apple”. Tudo funciona muito bem quando estamos com nossos iPhones, iPads, MacBooks e iPods. Se eu tenho um iPad, mas utilizo um PC, algo fica estranho. Funciona, mas fica estranho.

Assim como sistema dos mobiles, os sites precisam seguir a mesma fórmula de simplicidade e foco. Por isso, criar sites para mobiles é uma arte. É um jogo de prioridades. Você precisa saber o que é importante na página e focar naquilo. Há um bom trabalho de arquitetura de informação que precisa ser feito. E não se engane, as vezes é muito mais dificil desenvolver um projeto de arquitetura para mobiles do que para versões full.

O iPhone, e agora o Windows Phone, se destacam muito por conta dessa harmonia que citei acima. Há uma ligação em tudo ali. Quando você aciona o Safari, ele tem uma interface intuitiva, bem acabada e que não agride a usabilidade do site. O iPhone tem um browser 100% atualizado com os Padrões Web e isso ajuda um bocado o desenvolvimento de interfaces inteligentes.
E a Apple se preocupa com essa harmonia da qual estamos falando, ela prepara uma série de materiais que ajudam os desenvolvedores. São guias de desenvolvimento e referência com os princípios de design e usabilidade que garantem a experiência completa. Por causa disso os desenvolvedores e designers fazem ótimos apps, tornando a experiência do usuário completa e uniforme durante o uso do dispositivo.

É por isso que a vale a pena municiar os desenvolvedores e designers do mundo todo, para que a experiência não termine quando o consumidor feche o seu aplicativo ou abra o navegador. Experiência tem começo, meio e fim. A Apple se preocupa com essas etapas. Ela sabe que se o site abrir “quebrado” o consumidor vai xingar primeiro o aparelho e não site. Tudo é uma única experiência. Começa no sistema do aparelho e termina no site de um terceiro.

O resto dos aparelhos começam pecando por ter um browser ruim ou uma interface de uso complicada. Na maioria os browsers não dão suporte algum aos Padrões. Isso é um pecado. Se eu tenho um Smartphone, eu passarei mais tempo na internet, conectado, do que falando ao telefone. Esse é apenas um ponto sobre o porque um dispositivo móvel precisa ter um browser decente.

O usuário tem uma boa experiência quando consegue com sucesso a informação que procurava, sem bloqueios. Se ele consegue passar esse processo com sucesso, como se o dispositivo (mobile, desktop, notebook, leitor e tela etc) e o site/sistema fossem transparentes, aí cumprimos com o nosso dever.