Nesse artigo, vamos mostrar o básico que todo webdesigner precisa ter desse framework javascript.

Mas espera aí, o que é um framework ?

“Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação.” — Fayad e Schmidt

Resumindo: é um conjunto de classes que fornecem facilidades genéricas, tornando o desenvolvimento cada vez mais rápido e organizado. (write less, do more / slogan do jQuery)

Javascript

Antes de começar com jQuery vamos ver o basicão de javascript:

Concatenando e declarando variáveis

//declarando variáveis
var foo = 'olá';
var bar = 'mundo';
// para concatenar, usa-se "+"
var foobar = foo + ', ' + bar; // resultado: "olá mundo"

Operadores de comparação

var foo = false;
/* as "chaves após o if são obrigatórias
* a condição só é executada se for verdadeira
*/

if(foo) {
//foo é false, esse código não será executado
alert('foo é verdadeiro');
} else {
//esse código será executado
alert('foo não é verdadeiro');
}

Javascript inline (onde vamos escrever os códigos acima)

Javascript inline (onde vamos escrever os códigos acima)

E aí, vamos ao jQuery?

jQuery()

Dependendo da velocidade da internet do usuário (e de alguns outros fatores também) alguns elementos do layout podem demorar um pouco para carregar completamente; com isso os objetos que queremos manipular com jQuery.

Para executar o código apenas quando o Javascript estiver pronto, usamos o $(document).ready:

$(document).ready(function() {
alert('javascript está pronto !');
});

$(function(){
alert('javascript está pronto !');
});

Okay! E agora ?

Se você não conseguiu entender (ou mesmo que tenha) aqui vai uma explicação do que são e para que servem os “seletores” de jQuery.

Um pouco da Estrutura

Em jQuery, vamos sempre usar essa estrutura básica: $(objeto) …

Entenda como objeto aquilo que queremos selecionar para manipular (trocar classe, mostrar, ocultar, animar, etc). “Selecionar” um objeto com jQuery é muito similar ao que fazemos no CSS (incluindo também suas pseudo-classes):

// selecionando tags
$('p');
$('h1');

// usando pseudo-classes
$('div:first'); // selection o primer div
$('div:visible'); // div's visiveis
$('#form :input'); // inputs dentro de form

Sendo assim, quando escrevemos $(document).ready(); o objeto em questão é o documento (document) chamando o evento ready() ;  que verifica se o documento está pronto. São os eventos e efeitos que fazem a “mágica” do jQuery acontecer.

Alguns dos eventos e efeitos mais usados

click()

Como o nome sugere, esse evento é ativado quando clicar  no objeto selecionado;

toggleClass() e toggle()

Esse evento serve para trocar a classe (toggleClass) ou o estado de visibilidade (toggle) de um determinado objeto;

fadeIn() e fadeOut()

Fazem o mesmo que show() e hide() – respectivamente – porém de forma mais elegante e menos “dura”.

css()

Com esse, é possível alterar qualquer prioridade css do objeto !

animate()

Esse é um dos mais legais. Faz animações com o objeto.

attr()

Funciona como um seletor, que “pega” o valor de determinado atributo ou “define” o seu valor.

html()

Define ou “pega” o valor que está entre as tags do objeto.

No próximo post vamos sair do lero-lero, colocar em prática o que vimos e criar alguns efeitos usando botões e formulários !

Até lá ;)

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• A importância de parceiros confiáveis
• Design de mensagens de erros
• Workflow – sites e softwares

O comentário (na programação web) é algo desnecessário ao funcionamento do site. Ele serve apenas para indicar algo a quem está lendo o código fonte ou trabalhando no back-end (por exemplo, em scripts de PHP ou JavaScript). O usuário final não vai ver esses comentários no site, então a utilidade deles é exclusivamente ao programador / web designer.

Um código comentado salva muito tempo quando você for editar algo num site e precisa saber o que você está editando. Por exemplo, um site pode conter várias DIVs dentro de outras DIVs. E pra saber onde que fecha um e abre outro? Código indentado pode ajudar e alguns softwares até indicam qual é a DIV sendo fechada – mas e quando você está usando o bloco de notas só para fazer algumas alterações mínimas?

Outro exemplo seria o uso de comentários nos arquivos CSS; fica mais fácil de encontrar as IDs e classes usadas em determinadas áreas de um site (cabeçalho, barra lateral, menu, etc). Lembre-se que “organização = produtividade”.

Código comentado não facilita apenas a sua vida, mas a de um possível futuro programador ou web designer que precise alterar algo no site.

Se você não usa código comentado, comece a usar! Você talvez não note a diferença na sua produtividade de início, mas veja daqui a um mês quando tiver que editar aquele código novamente.

Você usa códigos comentados nos seus sites? Se não, por quê? Comente!

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• A internet do futuro tem lugar para web designers?
• Mega sorteio Design Blog e Adobe!
• Design Blog Podcast – Episódio 04

Uma das frases que qualquer um que trabalhe com web verá muito é “Conteúdo é rei“. Se usa no SEO, nas mídias sociais, na publicidade, no design e em tantos outros lugares (e dita por tantos outros profissionais) que chega a ser inquestionável a importância desta frase. O conteúdo é, de longe, a coisa mais importante na web.

Sim, pasmem: eu, um designer, estou falando que o conteúdo é mais importante que o design. Estou destronando minha própria profissão! Ok, não seremos tão dramáticos.

O design não é nada sem conteúdo. E isto coloca a gente em uma posição delicada: e quando o cliente não sabe disto?.

De nada adianta ter um site fantástico, com a melhor usabilidade, com a melhor tipografia, com as melhores cores de todo universo web se o texto está escrito em “miguxês”, não possui pontuação e não faz sentido algum.

E mesmo se o texto está escrito certinho, de que adianta querer tentar vender algo no seu site se você não tem um serviço de atendimento ao cliente? Se demora 24h úteis para até responder um email? Ou se você simplesmente não atualiza o blog, a seção de notícias ou até mesmo a página inicial com um aviso da existência de descontos em produtos do seu site?

Se você for a uma loja física e ela estiver coberta de pó, com teias de aranha ou até mesmo parecer estar totalmente descuidada, você compraria nela? Mesmo se tivesse bons preços e uma faxada legal, você provavelmente não confiaria muito, certo? Por que seria diferente na internet?

Vários clientes meus querem mergulhar de cabeça no mundo digital, ter seu próprio site, mas não querem se dar ao trabalho de cuidar dele. É como ter um filho só por que bebês são fofos, mas não se dar ao trabalho de alimentar a criança. Ok, a analogia parece ter ido longe demais, mas deu pra entender.

Conteúdo é rei

Um conteúdo atualizado, escrito corretamente e um cuidado com o site são requisitos básicos para se ter um site de sucesso. Dá pra viver sem um design genial? Dá. Mas dá pra ter um design genial e conteúdo porcaria? Também – só não espere chamar a atenção de ninguém.

E você? Tem clientes que te pedem um site super bacana e não cuidam dele? Deixe seu comentário!

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Código comentado salva vidas!
• Design Blog Podcast – Episódio 04
• O que é um Teste A/B de Usabilidade?

Se você não sabe o que é SEO, quer saber mais sobre SEO, quer viver de SEO, escute nosso podcast sobre SEO ;)

Alguns links relacionados a este episódio:

• MestreSEO
• SEOmoz
• O que é Black Hat SEO?
• Site do Nagüeva
• Twitter do Nagüeva

Nova capa do podcast

Pra quem não estava sabendo, pedimos aos designers que acompanham o Design Blog para que enviassem artes para a capa do podcast. E o ganhador foi: Thallez Melo! Eis a capa criada por ele:

Tivemos outros que chegaram perto de serem escolhidos; Bruno Lima, Daniella Etinger (que forneceu uma defesa bacana) e Eduardo Oliveira respectivamente.

A todos os outros que participaram, meus sinceros agradecimentos! Teve muita capa boa, mas não tínhamos como escolher todos.

Download do podcast

Este episódio tem 38:52 de duração, pesa aproximadamente 28mb (formato MP3) e está em qualidade de 96kbps. Esse é o link direto para o download (caso você esteja lendo o feed), e caso você queira escutar direto no site acesse o post aqui.

Aproveite para assinar o feed exclusivo do podcast aqui ou pegar o podcast direto no iTunes por este link. Ou se preferir, assine o feed do site inteiro neste link.

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Regulamentar a profissão de designer – sim ou não?
• Mega sorteio Design Blog e Adobe!
• Código comentado salva vidas!

Mensagens de erro não aparecem apenas no sistema operacional. Eles ocorrem em qualquer interface que tenha um código por trás – até em sites. E muitas vezes, estas mensagens de erro se resumem ou a algo muito genérico como “Um erro ocorreu. Fechando aplicativo” até aquelas mensagens que parecem ter caracteres aleatórios:

Além destas mensagens, há ainda aqueles avisos que você não sabe do que se trata. Um exemplo clássico é o alerta JavaScript usando em sites, que podem conter de tudo: desde uma mensagem de “sucesso” até uma de “falha”. Ambos, sem distinção alguma.

Como criar mensagens de erro compreensivas?

Como designer trabalhando em algum projeto, há algumas coisas que você pode fazer para facilitar o entendimento da mensagem de erro.

Vamos levar em conta o exemplo do formulário de contato. Ao clicar em “Enviar”, o formulário pode retornar um de dois resultados: sucesso ou falha. O primeiro passo, é deixar óbvio o que é sucesso e o que é falha.

Conseguir isto é fácil. Um aviso retornando uma mensagem de “sucesso” pode usar bastante a cor verde, culturalmente associada ao sucesso e/ou falta de erro. Já uma mensagem de “erro” ou “falha” necessita de (por exemplo) um ponto de exclamação grande e vermelho. Ou, se quiser ser bem minimalista: use como cor de fundo para a caixa de aviso o verde ou o vermelho.

Mas cuidado: não vá dar uma de espertinho e inverter o significado das cores, ou até mesmo usar cores totalmente diferentes. O amarelo, por exemplo, não poderia ser usado para indicar “sucesso”, pois é uma cor que remete a “atenção”. Teoria das cores é um assunto importante neste caso.

E se você não puder usar cores no seu projeto? É possível indicar um aviso usando apenas preto e branco e tipografia diferenciada.

Informe uma mensagem de erro

Talvez uma mensagem de erro escrito apenas “Erro” não seja muito útil ao usuário. O que aconteceu? Quem errou? Foi o computador ou foi eu? Não fiz algo certo? O que não fiz certo?

Quanto mais objetivo for a mensagem de erro, menos o usuário irá errar na próxima tentativa. Mensagens como “Erro na linha 42341, código 234#49%9210″ não diz nada de útil ao usuário. Já um “você esqueceu de preencher o campo de Nome” é bem mais objetivo.

Ofereça soluções para consertar o erro

Depois de informar um erro objetivamente, o próximo passo é oferecer uma solução para este erro.

A solução pode ir de um simples “Clique aqui e preencha o campo que faltou” até um “Por favor, entre em contato com o administrador pelo e-mail (…) e detalhe o problema”. Quanto mais fácil for a solução do problema, mais chances há do usuário consertá-lo sozinho.

O usuário tentou enviar um formulário mas esqueceu de preencher um campo? A mensagem de erro deve apontar isto, deixando claro: “Você não preencheu o campo X. Clique aqui para voltar e preencher este campo”. Ele preencheu um e-mail que não segue a regra usuario@domínio.tld? A mensagem de erro deve incluir: “Seu e-mail parece inválido. Por favor, verifique se ele foi digitado corretamente”. E por aí vai.

Use uma linguagem a altura do usuário

“Os inputs não possuem valores válidos” é uma frase confusa que um usuário comum pode não entender. “Você preencheu um telefone inválido no campo Telefone” já é uma frase muito mais fácil. Use uma linguagem leiga para que qualquer usuário entenda.

Resumindo

Mensagens de erro precisam fazer 3 coisas. Elas precisam comunicar ao usuário que:

• Um erro aconteceu
• O que aconteceu
• O que pode ser feito para corrigí-lo

Um exemplo são as janelas de confirmação de envio e erro de envio que uso nos formulários de contato dos blogs que eu crio no xCakeBlogs:

No caso da mensagem de erro, ao clicar no “X” o usuário é redirecionado a página anterior onde todos os campos ainda estão preenchidos. Lá, ele pode consertar o erro.

Inspiração: CommerceTuned

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• jQuery: o básico que todo designer precisa saber – parte I
• Design Blog Podcast – Episódio 04
• Design Blog Podcast – Episódio 03

Nas palavras de Chapman:

Como web designers e web developers, o que a internet reserva para os usuários no futuro é de vital importância para nossas vidas. Se o futuro da web implica em mudanças radicais para todos, precisamos entender como isto vai afetar o que fazemos como meio de vida e o que vamos precisar mudar em nosso trabalho para não ficar de fora – se é que é possível.

“O futuro é conteúdo e informação”

Se você for como a maioria dos consumidores tecnológicos atuais, você possui um smartphone – um aparelho móvel (celular) que pode acessar a internet. Seja um aparelho da Apple (iPhone, iPod Touch, iPad, etc), um Android ou até mesmo um Blackberry se você for um executivo empresarial, você tem acesso aos seus projetos profissionais e pessoais – como checar e-mail ou procurar entretenimento. E a autora questiona: “Quanto disto você faz pelo navegador do seu celular?“. A resposta é provavelmente “não muito“.

Usamos apps (aplicativos) específicos para checar e-mail, apps para verificar seu status no Facebook, Twidroid, Tweetdeck ou Gravity para atualizar o seu Twitter, apps específicos para ver vídeos no YouTube, Pandora ou Last.fm para escutar música.

Até mesmo nos desktops ou laptops estamos cada vez mais usando aplicativos para acessar alguns serviços – desde o GMDesk que acessa o seu GMail até o Tweetdeck para ver o seu Twitter. Temos até opções como o Fluid ou Prism para transformar qualquer site em um aplicativo independente do navegador. Sem contar o Google Chrome OS que transforma seu computador em um navegador, rodando aplicativos nas nuvens.

E as versões de sites móveis? Muitos deles são similares entre si, sendo que a única coisa que muda é o conteúdo. E não é por menos: quem acessa por aparelho móvel acredita que o design é irrelevante. “Por quê?” você se pergunta. A resposta é simples: eles estão acessando o site móvel exclusivamente pelo conteúdo. Claro que isto não quer dizer que não apreciem um bom design, desde que a interface não complique ou interfira com a habilidade do usuário encontrar o que precisa.

Agregadores são o futuro / presente da web

O que são estes agregadores? São serviços como o Google Reader, Twitter e Facebook. Eles juntam o conteúdo de diversas fontes e apresentam sob uma única interface.

Veja o caso do Facebook: você raramente precisa sair do site para ter acesso ao conteúdo postado lá. Vídeos? Assista diretamente online. Feeds RSS? Você mal sai do Facebook para ler.

Nossos inimigos?

O Google é pior ainda neste caso. É só ver a quantia de produtos que eles oferecem. Muitas vezes você nem precisa sair da página de busca para conseguir uma informação. Em breve, você poderá ver o conteúdo do que você buscou direto pela página deles.

Nem tudo é desvantagem para os donos de sites

Claro que com a queda de acessos ao site, a publicidade (como o Google AdSense) cairá. Em contrapartida, o consumo de banda de cada site será muito menor. Sem a transferência de gráficos, folhas de estilo CSS e processamento de informações, consumo de banda será drasticamente reduzida.

Outra vantagem é o aumento do controle por parte do usuário. Eles podem definir como eles vão visualizar o conteúdo, não correndo mais o risco de ter que entrar em sites sem acessibilidade e não encontrar o conteúdo que precisam. Finalmente usuários com deficiências teriam uma presença muito maior na web.

O que isto tudo implica ao web designer?

O conteúdo passará a ser dinâmico. Ele não está mais limitado a um site somente. Com o RSS, você já pode acessar o conteúdo deste blog sem nunca ter que acessar ele (pelo nosso feed, por exemplo). E números não me deixam mentir: atualmente conto com 2.869 assinantes de feed que acessam o conteúdo do meu blog, chegando perto de ultrapassar os 3.000 acessos diretos diários que este blog possui. O Twitter é outro: são atualmente 4.700 seguidores que além de terem acesso ao conteúdo deste site, ainda podem acessar os vários links interessantes que publico diariamente.

E o que tudo isto representa a nós, web designers? Bom, se a web se tornar um lugar só de aplicativos e agregadores, a necessidade de se contratar um web designer será bem menor. Empresas não vão achar necessário contratar alguém para fazer um site quando eles podem apenas utilizar um template pronto e enviar todo o seu conteúdo para o Google, Facebook e Twitter.

Por outro lado, desenvolvedores vão passar por um “boom” de negócios. A procura pelo desenvolvimento de apps será muito maior. Claro que será necessário de um designer para que o app funcione, mas a demanda será muito menor do que para um site.

Como isto nos afetará, especialmente no Brasil?

Não dá pra negar que muito do que a Chapman falou é verdade. Houve um aumento significativo de aparelhos móveis com acesso a internet e o Twitter tem se tornado um serviço muito popular aqui no Brasil. No entanto, o Brasil ainda está muito atrás dos Estados Unidos e Europa no quesito “usuários de tecnologia”. Por exemplo, o Facebook está tendo uma participação de mercado brasileiro que aumenta a cada dia, mas ainda é muito inferior ao Orkut. O povo brasileiro ainda é leigo quando o assunto é a nova tecnologia.

Mas é só ver os números: como falei, tenho uma média de acessos diários de 3.000 visitas únicas. Assinantes de feed, chega a quase 2.900. Já no Twitter, tenho 4.700 seguidores. As pessoas estão passando a preferir poder centralizar todos os seus sites em um lugar só. E a tendência é que mais pessoas passem a aderir a estas formas de visualizar conteúdo.

Ao contrário dos Estados Unidos e Europa, acredito que estamos pelo menos a 3 anos de distância de termos um público móvel igual ao público que acessa pelo desktop. E talvez 5 anos para que o público móvel ultrapasse o número de acessos de quem acessa pelo navegador. Isto não quer dizer que devemos passar a ficar preocupados apenas por volta do ano de 2014!.

Claro, o web design não vai se tornar algo obsoleto nos próximos 10 anos, mas talvez a necessidade de se contratar um web designer caia bastante. Temos que ficar por dentro do que está acontecendo na web e como ela está mudando. Precisamos ficar atentos e tentar inovar onde for possível.

Uma coisa eu posso garantir: quem parar de estudar hoje, estará sem emprego até julho de 2012.

E você? Acredita que há um lugar para web designers na web do futuro? Ou já estamos perdendo espaço na web atual? Comente!

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Código comentado salva vidas!
• Mega sorteio Design Blog e Adobe!
• Design Blog Podcast – Episódio 04

Tipografia na internet sempre foi uma coisa meio problemática. Apesar dos diversos métodos existentes hoje em dia, até bem pouco tempo atrás as opções eram realmente limitadas. Navegadores que não renderizavam direito, regras CSS pouco conhecidas e usadas, layouts feitos em tabelas. Tudo isso atrapalhava a informação que dificilmente era apresentada de uma forma aceitável.

E, na minha opinião, a tipografia é o maior alicerce do webdesign. Quando apresentamos conteúdo numa página, na grande maioria dos casos estamos trabalhando com alguma forma de texto. Lidamos sempre com palavras. E por isso eu considero uma das habilidades mais louváveis de um bom webdesigner, fazer bom uso da tipografia.

Este artigo é sobre algumas técnicas para facilitar o seu trabalho na hora de criar/desenvolver uma boa tipografia na web. A começar pelas fontes.

Nota: Curiosamente, enquanto eu escrevia esse artigo, eu me deparei com mais dois artigos na internet que tratavam de temas muito parecidos. Um em português e outro em inglês. Apenas gostaria de citá-los aqui porque, de alguma forma, eles influenciaram o que eu estava escrevendo e também porque são duas ótimas fontes sobre algumas técnicas aqui descritas.

Web-safe fonts

Na época em que o CSS2.1 foi desenvolvido, não havia muita necessidade de uma especificação para usar fontes no CSS que não as do sistema operacional (na verdade até havia o rascunho do @font-face, mas acabou não indo pra frente). E com isso em mente foi convencionado o que se chamou de web-safe fonts. Um grupo de fontes que… mais ou menos… estavam nos sistemas operacionais mais comuns. Mais ou menos porque as fontes eram parecidas, mas não as mesmas.

Felizmente a propriedade font-family (ou apenas font) aceita substitutos caso a fonte específica não seja encontrada. Por isso quando declaramos uma fonte da maneira convencional, precisamos da versão windows, Mac e uma genérica caso as duas primeiras não existam.

font-family: Helvetica, Arial, "sans-serif";

Seria um trabalho cansativo ficar descobrindo qual fonte combina com qual em cada sistema operacional. Alguns softwares (como o Adobe Dreamweaver) até montaram stacks de fontes para ajudar. Mas, na minha opinião, este é o melhor stack de websafe fonts já feito. Reparem como até separação por título e parágrafo foi pensada. Esse autor realmente merece ir para o céu.

Image Replacement

Isso é usado geralmente em sites estáticos quando queremos que um título (por exemplo) dê lugar a uma imagem. Em resumo basta definir o elemento como block, aplicar a imagem de background e empurrar o texto 9999px para a esquerda com text-indent. Uma dica: se o elemento for um link, overflow:hidden; previne que uma caixa pontilhada que some no lado esquerdo da tela apareça quando clicado.


#logo{
display:block;
background: url(logo.png) transparent;
width:100px;
height:100px;
text-indent:-9999px;
overflow:hidden;
}


Substituição por Javascript/Flash/PHP

Essas são técnicas (bem elaboradas eu diria) para se resolver o problema das web-safe fonts. Mas nenhuma é perfeita.

As mais comuns são Sifr, Cufón e FLIR.

SIFR basicamente utiliza Flash para renderizar as fontes e javascript para colocá-las no lugar correto. Infelizmente requer que o usuário tenha javascript e flash habilitado. Cufón utiliza o elemento Canvas do HTML5 e VML no Internet Explorer para renderizar o texto com a fonte selecionada, mas o texto não pode ser selecionado. FLIR envia uma request ao servidor (PHP apenas) para criar uma imagem com o texto de marcação usando a fonte que você quer. Mas denovo… nada de texto selecionável.

Para saber mais a respeito dessas técnicas:

• Tipografia em sites com conteúdo dinâmico
• Cufon vs sIFR vs FLIR

@font-face

Ah… A grande esperança da tipografia de qualidade na internet.

Essa é a minha propriedade favorita do CSS3. Primeiro porque já podemos usá-la e ela funciona corretamente em todos IEs (com a extensão EOT infelizmente, mas já é alguma coisa). Segundo porque finalmente podemos usar a fonte que quisermos na web. Claro, com as devidas restrições de direitos autorais. Mas o interessante é que já existem sites especializados em distribuir fontes grátis usadas no @font-face.

• Font Squirrel (meu preferido)
• 10 Great Free Fonts for @font-face embedding
• Fonts available for @font-face embedding

Como usar

Para usar o @font-face, primeiro precisamos definir a fonte num seletor separado e depois declarar normalmente no elemento desejado. É importante utilizar o formato TTF(padrão) e EOT(formato fechado utilizado pela microsoft). Assim, garantiremos que ela funcionará em todos os navegadores modernos.

Por exemplo:


@font-face{
font-family: Alexandria;
src: url(Alexandria.eot);
src: local(Alexandria), url(Alexandria.ttf) format(“opentype”);
}

p{
font-family: Alexandria, serif;
}


Além disso, algumas empresas como o Typekit oferecem fontes de qualidade por uma mensalidade (ou de graça no plano básico) para usar em seus projetos.

Problemas

O único problema ainda na versão atual do @font-face é que em alguns navegadores ele é dependente do anti-aliasing do sistema. Por exemplo, no firefox 3.5 num windows XP com a opção cleartype desligada, a maioria das fontes fica horrível. Por sorte, do Windows Vista em diante, a Microsoft optou por deixar o cleartype ligado por padrão. Mas o problema é que se for usada num site onde grande parte dos usuários utiliza windows xp, teremos problemas como esse aqui.

Eu não quis aqui apenas simplificar as possibilidades de tipografia na web. Mesmo porque esse é um assunto muito complexo para apenas um post. Apenas apresentei as melhores formas (na minha opinião) de mostrar as fontes num site.

No próximo artigo vou falar mais especificamente de CSS e do que é possível fazer com as propriedades para melhorar a aparência do seu texto.

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• Código comentado salva vidas!
• A internet do futuro tem lugar para web designers?
• jQuery: o básico que todo designer precisa saber – parte I

Este mês, o Google anunciou que o suporte ao Internet Explorer 6 – navegador da Microsoft lançado em Agosto de 2001 – será gradativamente deixado de lado. Os primeiros produtos a serem alterados serão o Google Docs e editor Google Sites, que a partir do dia primeiro de Março deste ano podem ter certas funcionalidades desabilitadas, além de possivelmente conter bugs que impeçam o produto a funcionar corretamente. Mais além neste ano, o Google Mail (GMail) e Google Docs também perderão funcionalidades nos navegadores mais antigos.

Já é possível ver diversos avisos ao acessar sites de produtos do Google com o IE6, avisando sobre a falta de suporte futura. Mas qual a implicância desta ação?

A web mudou muito nos últimos 5 anos, quem dirá nos últimos 10. O IE6 não suporta novas tecnologias como CSS3 e nem HTML4. Mesmo assim, de acordo com a W3C, até Dezembro de 2009 o Internet Explorer 6 ainda possuía 10,9% do mercado de browsers (sendo que o IE7 tem 12,8% e a versão 8 do navegador já tem 13,5% do mercado).

Enquanto muitas empresas de desenvolvimento web já deixaram de dar suporte ao IE6 por um simples motivo: é quase necessário fazer dois sites – um para rodar no IE6 e outro para rodar em navegadores de verdade (IE7+, Firefox 3+, Safari 3+ e Chrome 4+), fazendo com que o tempo de desenvolvimento suba e o custo seja maior.

Ditando a moda

Lembra o que falei sobre grandes empresas ditarem a moda? Pois bem. Enquanto muitas empresas de pequeno e médio porte já não estavam dando mais suporte ao antigo navegador, as maiores já não podiam se dar ao luxo de fazer o mesmo devido ao fato que, como apontei, o IE6 ainda tem uma parcela considerável do mercado de navegadores web.

O Google ao dar esse primeiro passo está desencadeando uma reação em cadeia onde site após site ficará debilitado quando acessado por navegadores mais antigos, pois desenvolvedores irão dar mais atenção as novas tecnologias. Eu até já falei sobre as coisas que poderemos fazer assim que o IE6 deixar de ser um incômodo – e acreditem, este ano é o ano que enterramos este navegador.

Implicância aos usuários de IE6

Tem muito desenvolvedor por aí que acha que quem usa IE6 usa por opção. E esses mesmos desenvolvedores não procuram saber o por que destes usuários existirem. A verdade é que a maioria dos usuários atuais deste navegador são obrigados a usarem-no.

Empresas que não tem foco na web, universidades, repartições públicas, etc. São apenas alguns exemplos de lugares onde os computadores são mais antigos com sistemas operacionais mais atrasados. Lembro que na faculdade onde eu estudava, até pelo menos 2 anos atrás ainda estavam usando Windows 2000 com o IE6. E são bloqueados para a instalação de novos navegadores.

São milhares de usuários que estão presos com navegadores mais antigos e nem sempre por preguiça dos administradores de rede: muitas vezes, por donos de empresas que não vêem vantagem de atualizarem os computadores (já que o foco principal não é este).

Pode parecer que esta obrigação por finalmente atualizar é o correto a se fazer, mas podem ter certeza que este ano milhares de dólares serão gastos no mundo todo para melhorar computadores e atualizar sistemas operacionais. Infra-estruturas inteiras serão modificadas afim de que os usuários destes computadores possam ter o acesso mais básico a informações na web – por exemplo, e-mail e quem sabe até sistemas de busca no futuro próximo (quem garante que o Google não irá atualizar a página principal deles apenas para aceitar navegadores mais atuais?).

Finalmente, a mudança será necessária.

Embora a web finalmente será obrigada a se atualizar, muito dinheiro será gasto nisto. Sim, é pro bem geral da nação – afinal de contas, quem ainda vive em 2000 está uma década atrasado.

No mais, usuários de IE6, sejam bem-vindos a nova internet.

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• jQuery: o básico que todo designer precisa saber – parte I
• Código comentado salva vidas!
• Google Plus! A nova rede social do google!

Do mesmo modo que devemos nos preocupar em desenvolver um site que funcione bem em diferentes navegadores, incluindo os especiais para deficientes visuais, hoje é um fato que existe alguém que acesse seu site por meio de um dispositivo móvel. Nos dias atuais é importante que um site de adapte em diferentes mobile browsers (navegadores móveis – como os de celulares).

O maior problema é fazer essa adaptação do modo eficiente, o que deve-se levar em consideração durante o planejamento é que um site para mobile será visto em diferentes aparelhos e na grande maioria nem todos tem o mesmo suporte.

Um site bem feito, dentro dos padrões da W3c normalmente em principio já funciona em navegadores mobile, o que realmente devemos tomar cuidado é na hora de usar o CSS, nem todos renderizam bem as folhas de estilo.

Para solucionarmos esse problema podemos criar um filtro. Fazemos isso utilizando Media Queries. Elas nos permitem fazer isto. Um filtro onde definimos as características do dispositivo que acessará a página. Com isso, podemos criar um CSS específico para cada grupo de dispositivos que se encaixaram no seu filtro. Por exemplo:

Para desktops e notebooks:
<link rel=”stylesheet” href=”style.css” type=”text/css” media=”screen and (min-width:481px)” />
Mobile:
<link rel=”stylesheet” href=”mob.css” type=”text/css” media=”screen and (max-width:480px)” />

Durante o desenvolvimento do site devemos trabalhar sempre com tamanhos relativos, por exemplo, o conteúdo com 80% do tamanho total alinhado ao centro e a partir disto posicionar os outros elementos. Desta forma o site adapta-se de acordo com o tamanho da tela, em outras palavras, temos um layout liquido.

Como disse em outras oportunidades; pequenas mudanças geram grandes resultados!

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• jQuery: o básico que todo designer precisa saber – parte I
• Design de mensagens de erros
• Re-desenhando um site (dica)

Fonte do original (Valeu Fabio!)

Aproveite e siga o Design Blog no Twitter! Assim você fica por dentro das novidades no mundo do design, com links super interessantes.

Artigos relacionados

• jQuery: o básico que todo designer precisa saber – parte I
• Código comentado salva vidas!
• Construa e eles virão…ou não