TidBits

Jul 16

My-Guitar – Um Guitar Hero em HTML5, CSS3 e JavaScript

Nessa sexta-feira, teve um café com browser, um evento sediado pela w3c Brasil onde ela convida fabricantes de browsers a falarem dos seus produtos, por lá já passou o pessoal do Ópera, Firefox e até da Internet Explorer.

Porém, nessa edição o formato foi diferente, o tema era HTML5 e os convidados foram o Élcio da Visie (empresa de treinamento e desenvolvimento web que vai oferecer um curso de html5) e a AgênciaClick, onde esteve presente eu (Programador de Interface), Robson Dantas (Gerente de Tecnologia) e Ricardo Murer (Diretor de Tecnologia).

Durante a nossa apresentação, mostramos alguns protótipos de estudos que fizemos aqui na AgênciaClick, entre eles um player usando a tag <audio> simulando a interface do winamp e um jogo simulando o Guitar Hero:

Escolha Sua Música

O jogo está disponível aqui. Funciona para Chrome 5+, Ópera 10.5+, Safari 5+ e Firefox 3.5+ (sendo que para Firefox, é necessário estar hospedado em um servidor, ou seja, se você abrir o html como um arquivo, não funciona por questão de segurança do Firefox).

O jogo usa os conceitos de <audio> e <canvas> do HTML5, CSS3 e bastante javascript. Eu desenvolvi o game em 4 dias, ou seja, dá pra melhorar muito, devo aprimorar o código, colocar Ranking Online, mais músicas, etc.

Mas a idéia inicial era mostrar que pode ser feito um jogo em html5, com 20kb de JavaScript que antes só era possível ser desenvolvido em flash.

Jogo Guitar Hero em HTML5

Game Over - Guitar Hero em HTML5

May 6

Snake – Jogo em html5 usando Canvas

Nos próximos posts vou escrever um pouco das experiências em html5 que ando fazendo.

Pra iniciar, fiz um jogo simples daqueles que todo celular tem, usando somente o elemento Canvas.

O Canvas funciona como se fosse um “shape” do photoshop, você cria um elemento e lá você pode desenhar literalmente, circulos, quadrados, linhas, pontos, colocar backgrounds, usar degradê, etc.

O Canvas não dá suporte ao ie6, ie7 e ie8. Existe um elemento similar pra eles chamado “shape” e existem algumas libs em javascript que traduz automaticamente tudo o que for desenhado em canvas pra shape, ou seja, você chama o js que ele se vira com o resto. No caso, usei o explorercanvas (dica do Koji), mas também tem o html5.js e o canvas.js disponível pra gente usar.

O jogo é bem simples, não tem muitos recursos, poderia ter ranking, som, opções e um monte plus mas não era essa a intenção do primeiro post sobre html5. O jogo tem 8kb (somando html / css e javascript ) pros browsers que suportam canvas e 19kb para os que não suportam. não usa nenhum framework de javascript (do tipo jquery, mootols, prototype) e não faz requisição de nenhuma imagem, tudo que está na tela foi desenhado em canvas com javascript.

Deixei disponível o código fonte e para jogar é só clicar na imagem ou entrar aqui

Por sinal, recomento o Chrome ou Opera 10.5 que são os browsers mais rápidos da atualidade.

Quem jogar, fala quantos pontos fez.
=)

Jan 8

OpenSearch – Adicione seu site na barra de buscas do navegador

Os navegadores um pouco mais modernos tem uma barra de buscas pra você pesquisar na Internet.

opensearch

O Firefox em português por exemplo além da busca no Google já vem com busca pra Wikipedia, Yahoo, Buscapé, Mercado Livre, etc (e boa parte dos lucros da Mozilla vem dessa barra de busca, acreditem).

Mas o que pouca gente sabe, é existe um método em javascript capaz de adicionar uma fonte nova de pesquisa na barra.

Primeiro é necessário criar um xml:

< ?xml version="1.0" encoding="UTF-8"? >
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Buscar no TidBits</ShortName>
<Description>Programação Front End e Arquitetura de Informação</Description>
<InputEncoding>iso-8859-1</InputEncoding>
<OutputEncoding>iso-8859-1</OutputEncoding>
<Url type="text/html" template="http://www.tidbits.com.br/?s={searchTerms}"/>
<Image height="16" width="16" type="image/x-icon">http://www.tidbits.com.br/img/tidbits_fav_ico.gif</Image>
<Language>pt-BR</Language>
<Developer>Danilo Augusto Martins</Developer>
</OpenSearchDescription>

A estrutura como podem ver é bem simples, o único truque está na Url da busca :
<Url type=”text/html” template=”http://www.tidbits.com.br/?s={searchTerms}”/>

Onde {searchTerms} é a palavra que o site vai receber do Navegador, ou seja, o que o usuário digitou.

Depois, é necessario colocar no <head> uma linha específicando que existe uma aplicação opensearch:

<link title="Busca no TidBits" rel="search" type="application/opensearchdescription+xml" href="http://www.tidbits.com.br/opensearch.xml">

Agora o comando em javascript que faz isso é mais simples ainda, é só chamar o xml através do método AddSearchProvider:

window.external.AddSearchProvider('http://www.tidbits.com.br/opensearch.xml');">

Ou seja, de uma maneira porca, basta um onClick num link / botão:

<a href="#" onclick=" window.external.AddSearchProvider('http://www.tidbits.com.br/opensearch.xml');">
Adicione o TidBits na busca do seu navegador
</a>

E veja o resultado:

Adicione o TidBits na busca do seu navegador

O método não funciona em todos os browsers, pelos meus testes, funcionou no Firefox 2, Firefox 3 e Internet Explorer 7. Num total os 3 browsers, hoje, tem uma participação de 50% aproximadamente do mercado de browsers. Na especificação do IE8, diz que o método funciona, mas pelo que testei, não rolou, e ví bastante gente em fóruns reportando o mesmo problema (se alguém tiver alguma solução, poste aqui nos comentários por favor).

Mas, obviamente, o ideal é verificar o browser do usuário, e só mostrar o botão de adicionar se for um desses browsers:

Então vamos lá, crie o html:

<a id="opensearch" href="#">
Adicione o TidBits na sua barra de Busca do seu navegador
</a>

No css, deixe o botão com display:none :

#opensearch{ display:none; }

E no javascript:

var agt=navigator.userAgent.toLowerCase();
if(agt.indexOf("msie 7")!=-1 || agt.indexOf("firefox/2")!=-1 || agt.indexOf("firefox/3")!=-1) {
document.getElementById("opensearch").style.display = 'block';
document.getElementById("opensearch").onclick = function(){
window.external.AddSearchProvider("http://www.tidbits.com.br/opensearch.xml");
return false;
}
}

Bom, é isso.

Implementei um desses no meu site sobre o Corinthians, quem quiser ver (e obviamente estiver usando FF2, FF3 ou IE7), olha lá:

http://www.noticiasdocorinthians.com.br

Espero que tenham gostado.

Abraços,

Aug 18

Tradução de idiomas usando a API Ajax de idioma do Google

É um serviço relativamente novo, pouco usado, mas muito interessante.

A ferramenta de idiomas do Google, acredito que todo mundo já conhece. Porém pouca gente sabe que o Google oferece uma API em ajax para tradução.

E pra facilitar ainda mais, existe também um plugin de jQuery chamado jquery-translate que interage com a API do google, aí fica bem simples:

copy of tidbits Para traduzir um texto basta chamar o node do html pelo seletor do jQuery e chamar a função translate:

	<script type="text/javascript" src="js/jquery-1.3.2.js"></script>
	<script type="text/javascript" src="js/jquery-translate-1.3.9.min.js"></script>
	$(document).ready(function(){
		$('button#traduzir').click(function(){
			$('div#texto').translate('en')
		});
	});

No exemplo acima, quando clicarem no botão traduzir, irá traduzir todo o conteúdo da div id=”texto” para o inglês, a API do Google detecta automaticamente o idioma original.

Veja um demo abaixo que eu fiz:

Clique em uma das bandeiras abaixo do texto para traduzir para o idioma selecionado:

Quem quiser entender, deixei o exemplo disponível pra download.

Jul 29

Por que os usuários não trocam o IE? (E porque não adianta culpá-los)

Há muito tempo que o TidBits ficou só por conta do Danilo, e nos últimos tempos, nem ele tem dado conta.
Eu acabei ficando extremamente focada no meu trabalho como AI, e distanciando muito de tecnologia, desenvolvimento, webstandards (embora estejam altamente interligados!).

Mas essa semana, dois textos que eu li me fizeram querer voltar ao blog e tentar trazer para o TidBits uma discussão para convergir um pouco mais as necessidades dos desenvolvedores com as preocupações com o usuários, que são afinal, os elementos principais dessa coisa toda (se não fosse por eles – e nós, que também o somos – não estaríamos aqui discutindo, e desenvolvendo soluções).

Infelizmente, não foram textos que me chamaram a atenção pela qualidade – e sim pela confusão que suas autoras fizeram.
Não que essas pessoas sejam profissionais ruins, nem as conheço para dizer, mas é que de um tempo para cá parece que a discutir usabilidade e experiência do usuário se tornou mais comum. E com isso, muitas coisas (boas e ruins) reverberam por aí sobre o tema, e todo mundo lê e espalha essa informação. E quando isso não é sua área de especialização, fica um pouco difícil filtrar quem está (mais) certo ou (mais) errado no meio dessa gritaria toda.

Fato é que me chocou um pouco ver que tem gente confusa nessa história toda, propagando mais confusão.
Um desses textos era de uma jornalista, blogueira, que mantém um blog bacaninha sobre tecnologia e o texto dela – ela deixou bem claro, que era puramente opinativo – falava sobre um assunto recorrente aqui: o uso do problemático IE6.
Ainda assim, ela deixou uma opinião que me fez cair a ficha de que muita gente pensa assim: “O Internet Explorer (IE) só é o browser mais utilizado no mundo por causa do comodismo das pessoas.”

Eu sei que para maioria de vocês, que lêem o TidBits e são desenvolvedores, estão lá no dia-a-dia tendo que fazer mil gambiarras para aquele png funcionar no IE, a coisa pode parecer isso mesmo: a culpa é do usuário por ele ter um browser horrível e você precisar gastar o dobro do tempo para fazer uma transparência funcionar.

Acontece que um equívoco que a gente comete constantemente por estar “respirando” internet é examente achar que, pro usuário, isso realmente tem importância. Porque não interessa se ele usa o IE, o Firefox, o Opera ou o Chrome, não é questão de comodismo – é questão de relevância. Pense por exemplo em algo que você não dá a mínima, e tente comparar.

Eu por exemplo, não dirijo, e não ando de carro. Pra mim tanto faz se um modelo tem rodas x, ou freios sei lá o que. O importante é a finalidade: transporte. Dentro disso, as “features” do carro são completamente dispensáveis para mim. E se um dia eu tiver um carro, e puder trocar por um modelo bem mais completo o carro que eu tenho (que custe o mesmo), eu provavelmente não vou fazer. E não é que eu esteja acomodada – é que um carro para mim só serve para eu me transportar – e enquanto o carro que eu tenho servir para essa finalidade, não existe motivação para a troca.

É mais ou menos assim que funciona com o usuário: enquanto atender suas necessidades, o IE 6 vai ser o browser que ele vai usar. Isso pode fazer você pensar: então temos que deixar de dar suporte ao IE 6 para que as pessoas parem de usá-lo? Na teoria, passa por aí. Na prática, a nossa realidade pode ser diferente.

Tomar uma decisão arbitrária é um risco de negócio que precisa ser avaliado. Será que seu site permite que você sugira uma atualização no browser do usuário? Será que se um usuário não conseguir abrir seu site no navegador dele ele vai insistir em ver o que você tem para mostrá-lo? Isso é um grande DEPENDE.

Enquanto existe capacidade / disponibilidade para replicar a experiências do usuário em TODOS os browsers, estamos no mundo ideal. Quando isso não ocorre, podemos oferecer pro usuário uma versão simplificada, e sugerir que experimente uma interação mais rica com um navegador mais adequado. (O Twitter, por exemplo, adota a segunda opção, enquanto o Google funciona em quirks mode para suportar o IE 6).

De modo geral, é preciso entender que essa decisão é estratégica. Antes de optar por abolir ou não o suporte a um navegador, você precisa analisar o impacto disso – por exemplo, se você tem um site voltado para classes c e d, que utilizam principalmente lan houses, sugerir a instalação de um browser para o site funcionar, seria um tiro no pé.
No entanto, se você oferece algo especialmente diferente (como o Twitter) você pode se arriscar a tomar decisões – pois terá um usuário motivado a fazer adaptações para utilizar aquele ambiente.

Pra finalizar, um vídeo (em inglês), chamado “What’s a browser?” - para vocês verem o quanto as pessoas (não) estão preocupadas com isso:

PS: E culpem os usuários, se quiserem. Eles não darão a mínima, desde que eles consigam entrar naquele site, seja com o internet explorer, firefox ou uma roda.

Jun 4

O Bug do parse XML no IE com o ajax do jQuery

Post mais técnico seria impossível né? Enfim, se você leu o título e está lendo até agora é porque sabe do problema que estou falando: o ajax do jQuery tem um problema quando se trabalha com XML, o problema só acontece adivinha onde? No nosso querido browser Internet Explorer.

Mas como quase tudo na vida, tem solução:

Solução número 1 – Pare de trabalhar com XML e comece a usar JSON.

Solução número 2 – Existe um parseXML que funciona pro IE. E alguém de muita boa vontade que se chama Jonathan Sharp fez disso um plugin que pra jQuery que se chama XMLDOM .

E como funciona?

assim:

Forma normal (que normalmente dá erro no IE)

$.ajax({
	url: 'xml/erros.xml,
	type: "GET",
	dataType: "xml",
	contentType: "application/x-www-form-urlencoded; charset=UTF-8",
	success: function(xml){
		var htm ='';
		$(xml).find('item').each(function(n){
			htm += $(this).text();
		}
		$('#erros').append(htm);
	}
});

Com o plugin XMLDOM

$.ajax({
	url: 'xml/erros.xml,
	type: "GET",
	dataType: "html",
	contentType: "application/x-www-form-urlencoded; charset=UTF-8",
	success: function(xml){
		var htm ='';
		$.xmlDOM(xml).find('item').each(function(n){
			htm += $(this).text();
		}
		$('#erros').append(htm);
	}
});

E pra quem quiser evitar o trabalho, pode baixar o plugin direto aqui.

[]s

« Pr�ximo12 3 4 5 6 7 8 9 10 11 12 13...21 22 Anterior »