TidBits

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:

[sourcecode language="xml"]
< ?xml version="1.0" encoding="UTF-8"? >

Buscar no TidBits
Programação Front End e Arquitetura de Informação
iso-8859-1
iso-8859-1

http://www.tidbits.com.br/img/tidbits_fav_ico.gif
pt-BR
Danilo Augusto Martins

[/sourcecode]

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:

[sourcecode language="javascript"]

[/sourcecode]

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

[sourcecode language="javascript"]
window.external.AddSearchProvider(’http://www.tidbits.com.br/opensearch.xml’);”>
[/sourcecode]

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

[sourcecode language="javascript"]

Adicione o TidBits na busca do seu navegador

[/sourcecode]

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:

[sourcecode language="html"]

Adicione o TidBits na sua barra de Busca do seu navegador

[/sourcecode]

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

[sourcecode language="html"]
#opensearch{ display:none; }
[/sourcecode]

E no javascript:

[sourcecode language="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;
}
}
[/sourcecode]

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:

[sourcecode language="javascript"]

$(document).ready(function(){
$(’button#traduzir’).click(function(){
$(’div#texto’).translate(’en’)
});
});
[/sourcecode]

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)

[sourcecode language="javascript"]
$.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);
}
});
[/sourcecode]

Com o plugin XMLDOM

[sourcecode language="javascript"]
$.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);
}
});
[/sourcecode]

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

[]s

May 6

Firefox 3.5 Beta 4 executa Javascript mais rápido ainda

Primeiro devo admitir, dei uma sumida, caiu o número de posts aqui, mas tá dificil conseguir tempo, ultimamente, além do trabalho, estou fazendo freela e estudando e meio sem criatividade pra postar, espero que seja breve.

No post de hoje vou falar sobre duas coisas que me ajudam muito na minha profissão, Firefox e Javascript.

Ontem ví uma notícia, que a versão 3.5 Beta 4 do Firefox (que está demorando um tantão pra ser lançada), tem um algoritmo que executa Javascript 19% mais rápido do que a versão Beta 3, esta que também já é mais rápida que a versão atual do Firefox. Isso é bom pra quem é programador de interface, e principalmente pro usuário.

Comecei a usar o Firefox em meados de 2005, achei legal porque “tinha abas”. Na época eu era programador back end, e como a maioria, pouco me importava se meus sites rodavam em outro browser ou não. De lá pra cá eu, as empresas, as agências, os clientes, os navegadores, os sites e até os usuários mudaram. Hoje temos (todos nós) o conceito de webstandards muito forte, e hoje os próprios usuários também são mais exigentes… normalmente temos diversas opções pra qualquer tipo de serviço web, então se um site não funcionou no navegador do usuário, ele não muda de navegador, muda de site… procura por outro serviço que faz a mesma coisa, é claro que não serve pra tudo (como sites de bancos, malditos).

Comecei a programar em Javascript pois detestava sites em flash, e comecei a ver que em algumas aplicações simples, dava pra fazer o mesmo efeito em Javascript.

E depois, quando “descobri” o firebug, ficou tudo mais fácil.

Mais uma vez o Firefox contribui diretamente e incentiva o uso de Firefox pra desenvolvimento de interação.

Além do mais, até nas extensões do Firefox (como GreaseMonkey e Ubiquity) é possível fazer coisas muito interessantes usando somente javascript.

Enfim, usem firefox… =)

[]s

May 4

jQuerify - Adicionando jQuery para testar em páginas online

Nada mais fácil do que trabalhar com jQuery, e nada melhor pra aprender do que entender sites alheios.

Com o jQuerify (que acabou de ser atualizado) é possível (com a ajuda do firebug pra Firefox, debug bar pra IE, etc…), executar comandos jQuery (como jQuery.ajax ou qualquer outro) mesmo se o site não tiver jQuery carregado.

Basta executar um script (que o chamamos de jQuerify) no seu depurador de javascript ( no firebug, clique em console, cole o script no box da direita e clique em “Executar” ) e pronto, o script invoca o invoca o jQuery. Depois, para testar, ao invés de usar $ use o jQuery nos seus seletores.

Segue script abaixo.

[sourcecode language="javascript"]
(function() {
var s=document.createElement(’script’),
el=document.createElement(’div’),
b=document.getElementsByTagName(’body’)[0];
var otherlib=false,
startCounter=tryCounter=10,
delay=250,
msg=”;
s.setAttribute(’src’,'http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js’);
el.style.position=’fixed’;
el.style.height=’32px’;
el.style.width=’220px’;
el.style.marginLeft=’-110px’;
el.style.top=’0′;
el.style.left=’50%’;
el.style.padding=’5px 10px 5px 10px’;
el.style.fontSize=’12px’;
el.style.color=’#222′;
el.style.backgroundColor=’#f99′;

if(typeof jQuery!=’undefined’) {
msg=’This page already using jQuery v’+jQuery.fn.jquery;
return showMsg();
} else {
if(typeof $==’function’) {
otherlib=true;
}
document.getElementsByTagName(’head’)[0].appendChild(s);
}

[]s

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