Tableless » internet

Convencimento e educação = liberdade

Diego Eis — Thu, 15 Dec 2011 14:00:57 +0000

Os websites precisam parecer iguais em todos os browsers? Claro que não. Aí você fala assim: “Diz isso para meu chefe ou meu cliente.” E eu digo sim. Mas aí eu estaria fazendo o seu trabalho.

Uma das obrigações atuais do desenvolvedor client-side é educar e convencer. E não venha me dizer que isso é quase impossível porque eu já sei disso. Mas ninguém disse que é totalmente impossível, correto? Você vai encontrar muitos obstáculos, tenha certeza disso, mas você vai conseguir mudar a web brasileira e a do mundo se fizer isso e fizer bem feito.

Não estou dizendo para você chegar de supetão, colocar a mão na testa do seu chefe/cliente e dizer: “Sai desse corpo IE porque ele não te pertence!!” Isso seria legal de assistir, mas você seria certamente demitido. Estou dizendo para você se armar. Se municie de números, estatísticas, quanto o pessoal da sua área está trabalhando mais para fazer o projeto funcionar em browsers antigos e quanto de dinheiro está provavelmente sendo perdido ao fazer isso.
A conta é simples: calcule o seu valor hora e o valor hora dos seus colegas de projeto. Coloque impostos, coloque tempo extra etc… Depois multiplique esse valor pela quantidade de horas que vocês gastaram para arrumar layouts em browsers antigos, quanto tempo vocês gastaram para deixar tudo exatamente igual em todos os browsers. Inclue o tempo gasto para recortar imagens, procurar plugins milagreiros em javascript, o tempo que você passou solucionando os problemas de estruturação e etc, tudo isso deve contar no número final das horas. Faça um dossiê. Não precisa ser muito longo, mas precisa ser exato! Precisa conter todas as dificuldades que vocês tiveram que resolver para tentar deixar os browsers com os mesmos efeitos que os browsers novos. Depois disso tudo, em uma hora apropriada apresente para o seu chefe.

Para ajudar fizemos um PDF que explica exatamente quais as soluções vocês precisam adotar e alguns outros assuntos que seu chefe precisa saber para entender melhor esse conceito todo. Você precisa entender esse é um caminho longo. Você não (ou vai) convencer seu chefe/cliente de primeira. Isso depende muito do seu perfil e do perfil deles. Mas com certeza, se você levar informações relevantes e maduras as chances serão grandes, já que ninguém gosta de perder dinheiro.

Posts Relacionados

Mobile First – A arte de pensar com foco

Diego Eis — Tue, 13 Dec 2011 15:30:26 +0000

Durante muito tempo especialistas de diversas áreas previram o crescimento do uso dos dispositivos móveis. Demorou um pouco mas a previsão se tornou verdadeira. Hoje todo mundo carrega um pedaço de plástico com uma tela de vidro na mão o dia inteiro… quase uma extensão de nossos corpos.

Os dispositivos móveis se tornaram uma febre e vieram para ficar. É a melhor forma de fazer a inclusão digital para aqueles que não tem uma forma de ter um notebook ou um desktop em casa. Não estou falando daqueles smartphones de R$1500, mas dos muitos smartphones, com teclados qwerty, prontos para internet e que custam R$200. Isso sim é inclusão digital para as massas de verdade.

Alguns números

As vendas de smartphones já passaram as de PCs. A utilização de emails pelos dispositivos móveis aumentou em 36%. Sem contar que o tráfego de visitação de websites utilizando smartphones cresceu 600% em 2010!

O Paypal tempos atrás recebia algo em torno de $10 Milhões de dólares em pagamentos via mobiles. Por dia! Eles tem uma predição de movimentar algo em torno de 6 Bilhões só este ano! E em 2016 serão $31 Bilhões!

As perspectivas globais são enormes. Abaixo, veja um inforgráfico que o blog The Meta Cloud preparou. Cuidado para não se assustar.

O conceito

Você consegue entender estes números? Se sim, você vai entender que o conceito do Mobile First faz muito sentido, mas vai contra toda uma tradição de desenvolvimento de sites que você está acostumado. A ideia do Mobiles First é que comecemos a desenvolver e planejar projetos web, desde um pequeno site até um grande sistema, primeiramente para dispositivos móveis e somente depois para desktops/notebooks.

Algumas vantagens

Se o mundo inteiro está passando mais tempo acessando a internet com dispositivos móveis, não é muito sensato pensarmos primeiramente em fazermos sites para desktops/notebooks, não é? O fato é que ao colocar os mobiles primeiro lugar, desfrutamos de uma série de vantagens:

As capacidades técnicas são mais interessantes. Com o mobiles você pode brincar com o acelerometro, GPS, multitouch, giroscópio e etc. Isso amplia a experiência do usuário para um patamar que o desktop nunca terá.
Foco. Quem já teve que adaptar um site para mobiles entende que informação demais prejudica. Se focar nas ações essenciais que o usuário executará ao acessar seu site com um dispositivo móvel é o básico.
A atenção em áreas como Arquitetura de Informação, Usabilidade e Acessibilidade é aumentada. Em mobiles, decidir onde cada botão vai ser posicionado é tão essencial quanto a programação server-side ou um HTML bem feito.
Te prepara para outros cenários. Fazer sites mobile é só o primeiro passo. Mas e os grandes formatos como SmartTVs ou outros dispositivos? Não vai demorar muito para acessarmos a internet de qualquer dispositivo sem bloqueios ou restrições.

O design

O design também precisa ser revisto. Na verdade, o design mais do que nunca conta com as respostas e os conceitos de AI, Acessibilidade e Usabilidade. Se antes fazíamos festa porque a resolução dos desktops aumentaram e agora temos mais espaço para trabalharmos, nos mobiles o cenário é completamente o contrário.

Arquitetura de Informação

As informações que você previa no desktop precisam ser remanejadas, diminuidas e retrabalhadas para que se adaptem nas telas menores. A maioria dos celulares tem algo em torno de 320×480 pixels. Se não tomarmos cuidado, toda a informação pode se perder em uma tela tão pequena. No mundo mobile o simples é a palavra que manda.

Você pode perceber que alguns websites conseguiram resolver bem seus problemas de excesso de informação promovendo em seus websites mobiles apenas as ações realmente importantes e dando foco ao conteúdo que provavelmente o usuário irá consumir quando estiver utilizando um pequeno dispositivo.

Se você é usuário do Flickr, conhece aquele bando de opções que ele guarda em seu menu principal. São centenas de opções e ações que certamente não cabem em uma tela tão pequena.

Um estudo profundo certamente deve ser feito para que você saiba exatamente quais informações e ações serão mais úteis na versão mobile.

Mantendo informações importantes

Existem também outras formas de acomodar um grande número de informações sem que isso atrapalhe o usuário. Uma delas é criando menus dropdown ou separando uma tela que guarda as informações que serão menos utilizadas mas que são igualmente importantes para a utilização do site/sistema. Veja abaixo dois bons exemplos vindo dos sites Gmail e ESPN.

Onde os usuários utilizam seus mobiles e visitam seu site? Bem, de todo lugar. Algumas pessoas acham que usuários utilizam apenas quando estão em filas, ônibus, parados no trânsito etc. Mas algumas pesquisas mostram que 84% dos usuários usam seus dispositivos em casa. Isso mesmo… em casa. Veja bem: quando as pessoas estão em casa, elas preferem utilizar seus smartphones em vez do notebook/desktop!
62% utilizam enquanto assistem a TV. Até a TV perde atenção quando briga com os mobiles.

Não existem mais desculpas. Os browsers para mobiles estão tão modernos quanto os dos desktops. O hardware está muito mais poderoso, mais do que poderíamos imaginar a dois anos atrás. Existe um número gigante de usuários utilizando estes dispositivos, isso os torna potenciais visitantes e claro, compradores. Porque desperdiçar esta oportunidade?

Você pode ler mais sobre este assunto neste livro esperto escrito por LUKE WROBLEWSKI. Aproveite!

Posts Relacionados

Especificação para touch screens

Diego Eis — Wed, 22 Jun 2011 13:00:48 +0000

Até alguns anos atrás nós acessávamos a internet apenas utilizando computadores e celulares. Hoje existem aparelhos de diversos tipos. Temos até dispositivos como o Surface, ainda que seu uso seja mais restrito e específico. Mas não demora muito que outros dispositivos surjam e preencham alguma lacuna escondida. O importante é entender que cada aparelho tem sua forma de interação.

Hoje, as interfaces touch estão maduras e estáveis, que chegam a inspirar as interfaces dos sistemas desktops. Vide o que aconteceu com o OS X Lion e com o Windows 8. As principais ideias foram retiradas de suas respectivas interfaces mobiles: o Windows do Windows Phone e o Lion do OS X para iPad.
As interfaces mobiles e as interfaces desktop ficarão mais homogêneas com o passar do tempo, se assemelhando cada vez mais, contudo, as interações são totalmente diferentes. As interfaces criadas para cada dispositivo nos ajudam a distinguir os ambientes e também a forma com que o usuário interage.

Estamos acostumados com a experiência de interação com a ajuda do mouse. Isso foi desde os primórdios e provavelmente ainda será por bastante tempo. Nós desenhamos interfaces para ações baseadas no mouse ou qualquer aparelho que controle a setinha da sua tela. Criar interfaces touch é algo relativamente novo. Nós trouxemos ideias da interação com mouse para os dispositivos touch, mas grande parte das interações precisaram ser reinventadas porque o modo, o ato, a forma de interagir com a informação é diferente. Na interface touch você não “coloca o mouse” em cima do elemento. Você não utiliza teclas de atalho para executar ações. Normalmente as ações importantes estão expostas na interface, facilitando o acesso rápido. Isso é muito importante porque nos ensina criar interfaces mais intuitivas, com a curva de aprendizado menor.
Há também o outro lado da moeda, onde detalhes das interfaces touch não podem ser portadas para interfaces baseadas em mouse. Lembre agora na forma de como você gira uma imagem em um dispositivo touch e como você gira essa mesma imagem utilizando um mouse. A interface muda, o seu comportamento muda.

Sabendo dessas limitações você deve entender que não podemos simplesmente portar o visual de um determinado site para um dispositivo touch. Você pode dizer que “hoje fazemos isso e até agora está funcionando muito bem”. Mas pense melhor… a grande maioria dos sites que você visita hoje no iPad ou qualquer outro tablet, por exemplo, são sites onde a sua interação é limitada. O que você faz em um site hoje em dia? Clica nos links e lê. Salvo às vezes quando você visita um site mais “animadinho” com mais ações para entreter o usuário. Mas e se você faz um site onde é preciso rotacionar uma imagem ou fazer um ZOOM? Você precisará manter as mesmas ações nos dois cenários. E como antigamente, para manter o cenário das interfaces touch você precisa da ajuda de muito script.

Ambas as versões tem suas limitações e um legado de compatibilidade com seu sistema base que precisam manter.

A ideia de criar uma especificação destinada para as interfaces touch é que tenhamos controle sobre as ações do usuário, da mesma forma que temos nos desktops. Para isso eles estão mapeando uma série de eventos que específicos das interfaces touch. Assim podemos definir ações baseadas nessas interfaces. Estão participando da escrita desta especificação Doug Schepers do W3C, Sangwhan Moon da Opera Software ASA e Matt Brubeck da Mozilla.

Se você parar para ler a específicação, vai entender que poderemos controlar quando o usuário interage encostando o dedo na tela, movendo o dedo e também ao retirá-lo. Você poderá controlar a área de toque. Se o elemento for pequeno, por exemplo, você poderá aumentar essa área de toque para que o usuário não tenha dificuldades. Poderá acionar eventos no momento que o usuário rotacionar os elementos. Se você está fazendo um WebApp poderá acionar um menu contextual personalizado quando o usuário fizer um “tap” com dois dedos. O usuário vira basicamente um proctologista.

A especificação ainda é um rascunho mas já está mostrando que as possibilidades são imensas. Eu vivo me perguntando até onde irá o HTML, CSS e Javascript com essas novas mudanças. Será que vão continuar fáceis como são hoje ou tudo vai ficar complicado? Será que serão eles que farão todo o trabalho ou novas linguagens serão criadas para lidar com essas novidades? Who knows? Eu tenho um palpite, mas é assunto para outra hora.

Posts Relacionados

Porque é a web que comanda

Diego Eis — Wed, 27 Jan 2010 11:30:56 +0000

A AppStore fez sucesso. Bastante. Por vários motivos: um deles foi por conta da remuneração do desenvolvedor. Teve gente que ganhou milhares de dólares sozinho vendendo aplicações por 99 centavos. Obviamente isso chamou a atenção de muita gente, que começou a fazer aplicações enlouquecidamente para ganhar alguns trocados. Consequentemente um grande números de aplicações que não precisam ser instaláveis no aparelho, apareceram. Vários desenvolvedores não perceberam que dependendo do seu sistema, ele não precisa ser desenvolvido exclusivamente para ser instalado na plataforma do iPhone.

Hoje, aparelhos como o iPhone, que tem um browser com um bom suporte a HTML 5 e CSS 3, possibilitam criar sistemas e aplicativos baseados em web, com características, designs e comportamentos idênticos aos de aplicações instaláveis nos aparelhos. E o melhor, podem ser utilizados de qualquer lugar, pela web. Outro ponto negativo é que desenvolver para iPhone/iPod Touch é um bocado burocrático. Você precisa ter o SDK que só funciona no OS X, e você precisa aprender Objective C para programar os Apps para Apple. Em contrapartida, para fazer um App baseado em Web, onde seus clientes acessarão o sistema diretamente pelo browser do aparelho, é preciso saber Javascript, HTML 5 e CSS 3. Se você já é desenvolvedor Web, você já sabe desenvolver para iPhone, iPod Touch, Android e qualquer outro dispositivo similar.

Se você gosta dos efeitos de transição dos aparelhos, você pode fazê-los sem problemas utilizando JQuery ou CSS 3. Há até um plugin de JQuery chamado JQTouch, que permite fazer efeitos idênticos ao do iPhone. Esse plugin foi pensado exatamente para funcionar em Mobile Safari e outros aparelhos com browsers avançados, como no Android.

Um caso sobre o que estamos falando é a aplicação do Itaú. Se você tem um iPhone, baixe o aplicativo pela AppStore. Ao abrir o aplicativo, perceba que o sistema não faz nada além de mostrar o site do Itaú. É muito mais interessante e barato ensinar o usuário a visitar o site em vez de procurar um aplicativo e instalar. Não é necessário nem divulgar um endereço mobile do site – esse aliás é outra discussão.

Obviamente, há exceções. A maioria dos jogos, se não todos, e alguns sistemas disponíveis funcionam melhor (ainda) se forem instalados no aparelho. Mas a grande maioria dos sistemas, principalmente aqueles que o usuário simplesmente insere ou verifca informações e dados, podem ser servidos diretamente pela web.

No caso do iPhone, os sistemas que utilizam recursos do aparelho, como por exemplo fazer o aparelho vibrar, bluetooth, bateria, GPS e etc, precisam ser instalados. Isso não se aplica a alguns mobiles da Nokia que são baseados na plataforma WRT.
A plataforma WRT permite que você desenvolva aplicativos utilizando Javascript, HTML e CSS. E por meio de Javascript, você pode ativar os recursos que ter utilizar no aparelho. Nesse caso, há uma vantagem em cima do iPhone: você não precisa aprender Objective C. Basta saber Javascript, CSS e HTML.

O cenário de hoje é interessante. Tudo o que o desenvolvedor sempre sonhou em utilizar de HTML 5 e CSS 3 pode ser aplicado no desenvolvimento para web mobile. Os browsers estão mais espertos e a cada dia trazem novidades interessantes para melhorar o desenvolvimento dos padrões e da web. Realmente, daqui pra frente, é um novo mundo que se forma. Um mundo tão ou mais complexo que o desenvolvimento web para desktops como conhecemos hoje. Pra mim, é mais apaixonante.

Guidelines de User Experience da Apple.
Forum Nokia – Web Runtime

Posts Relacionados

Anotações soltas sobre como vender e comprar na internet (por um leigo)

Diego Eis — Mon, 14 Apr 2008 13:18:42 +0000

Você se conhece de verdade? Quando você compra alguma coisa, compra porque? Todo mundo diz que a ação de comprar é algo emocional. E por ser uma coisa emocional, fica mais difícil encontrarmos o real motivo pelo qual a pessoa compra ou deixa de comprar algo.

A Visie está vendendo um PDF sobre Produtividade. E com essa experiência pude tirar algumas lições. A principal delas é que algo digital ainda não substitui algo físico. O preço do PDF é bem parecido com o preço de alguns livros impressos. O conteúdo com certeza é o melhor que você encontrar sobre o assunto (jabá), então porque ainda encontro pessoas que não tem coragem de comprá-lo?

A internet é nova e ainda existem algumas transformações que precisam acontecer para que possamos ultrapassar barreiras interessantes. Há algumas perguntas que ilustram essa nossa jornada: Quando compro um livro, eu posso emprestá-lo. Sei que aquele livro vai voltar para mim, porque vou emprestar para um amigo de boa fé que vai me devolver depois de lê-lo. Mas e se eu compro um PDF? Quando empresto um livro, eu empresto e fico sem. Mas e o PDF?

Ainda não sabemos vender conteúdo. Na verdade ainda não sabemos vender conteúdo pela internet de forma que o usuário trate esse conteúdo como algo físico, algo palpável.
O mercado de música teve uma experiência interessante. Levando para o lado emocional: quando compramos um CD de música, não compramos por simplesmente comprar. Compramos porque gostamos da banda, a música deles traz boas recordações, te faz pensar em coisas que você gosta, de alguém que você gosta. Logo, quem vende CD não vende música, vende sentimento. Vende sensações, lembranças. Levando para o lado racional: essas lembranças custam caro. Um CD bacana custa por volta de R$20, R$30, R$50!
Hoje há outras alternativas, posso abrir o iTunes e comprar apenas 1 música. Aquela música que me traz as boas recordações, aquela música que me faz sentir bem. A diminuição do preço, neste caso, foi um dos pontos principais que ajudaram essa indústria específica a ganhar uma outra roupagem. A lembrança agora custa US$1,99. Não preciso comprar um CD, com capa, encarte e tudo mais. Algo físico. Algo palpável. Posso comprar aquela lembrança específica, colocar no meu MP3 Player e pronto. Se o preço é baixo, a pirataria perde força.

Essa fórmula já não pode ser aplicada ao pé da letra quando vendemos conteúdo textual ou vídeos, por exemplo. Cada um dos meios tem sua fórmula específica. Qual a razão emocional que levará o camarada a comprar um PDF? Qual a razão emocional que fará o camarada comprar um vídeo? Qual a razão emocional que fará o camarada a usar um serviço grátis? Ser grátis pode não ser o bastante para seduzir o usuário, mas possibilidade de saber o que o amigo dele está fazendo naquele exato momento é.

Claro que compramos também por necessidades. Se você precisa de algum tênis, comida, roupa, você compra. Quando isso se torna emocional? Quando você compra algo que não está precisando? Se você já tem um smartphone bacana, porque vai querer o iPhone? O seu smartphone não faz ligações, não guarda contatos, não executa programas? Talvez, como eu, você não saiba responder porque quer. Mas com certeza você sabe que quer. Com o usuário é a mesma coisa. Basta descobrir, como a Apple, o caminho emocional que fará o usuário desejar (não querer) seu produto ou seu serviço.

Posts Relacionados

IE8 – O sonho não acabou

Diego Eis — Sun, 09 Mar 2008 05:19:58 +0000

Para você se inteirar do assunto, leia Browser Targeting Version.

No artigo que recomendei acima, lá nos últimos parágrafos dei minha opinião sobre a antiga decisão da Microsoft:

Mesmo assim, acho que tudo deveria ser nivelado por cima. Porque os desenvolvedores que se preocupam e utilizam os Padrões da maneira correta, são os que devem marcar o browser? Não seria mais fácil criar uma metatag para marcar os sites que não devem ser renderizados com o suporte avançado de Padrões? Quem deve se preocupar, são os desenvolvedores que não dão a mínima para os Padrões. Eles sim devem trabalhar para deixar seus sites atualizados.

A Microsoft voltou atrás com a decisão do Browser Targeting Version. Eles decidiram que, por padrão, o IE8 irá renderizar os sites no modo mais complacente com os Padrões Web possível, esse modo está sendo chamado de “Super Standards Mode”. Se você não desenvolve com Padrões, comece a se preocupar.

A idéia de nivelar tudo por cima, para mim, sempre foi o melhor caminho. Se você não desenvolve com Padrões, ou se desenvolve despreocupadamente, é melhor mudar. Caso você se encaixe neste perfil, há duas opções:

Ou você aplica o Browser Targeting Version. Isso fará com que o IE8 utilize o motor de renderização do IE7.
Ou pára de preguiça e aprende de uma vez por todas a fazer sites padronizados. Para mim, este é o melhor caminho.

Fazer um browser rigoroso, faz com que o mercado saia da zona de conforto e comece a pensar. Tudo sobe um nível e a coisa fica mais interessante. Mesmo a decisão sendo boa, a galera ainda tem um pé atrás (leia os comentários).

As atualizações do IE8 são ótimas. Há uma série de características que fazem muita falta no IE6 e no IE7 e que agora farão parte do IE8. Por exemplo, as pseudo-classes :before, :after e :focus. A propriedade content, que serve para gerar conteúdo, também estará nessa nova atualização. Entre outras facilidades que antes usávamos apenas em browsers como Firefox, Opera e Safari.

Me preocupo com o momento em que o IE6, IE7 e IE8 estarão sendo utilizados pelos visitantes, aí sim teremos um grande problema. Ou três.

Posts Relacionados

O Caminho Suave para o Tableless

Elcio Ferreira — Thu, 06 Dec 2007 20:11:11 +0000

A maior parte dos desenvolvedores web, designers ou programadores, começaram antes do surgimento dos movimentos em prol dos padrões web, usando tabelas para montar layouts em editores WYSIWYG, e ainda hoje este método é usado na maioria dos projetos de internet. Logo, é natural que muita gente, ao começar a entender o valor dos padrões, se pergunte como migrar do desenvolvimento “tradicional” para o desenvolvimento de código semanticamente coerente.

É um caminho muito duro o que separa o desenvolvedor acostumado a editores visuais do desenvolvimento de código coerente. E é muito comum que o designer desista após uma primeira tentativa frustrada de desenvolver um website tableless, com layout CSS e XHTML validado.

Por isso gostaria de propor um caminho gradual, mais suave, para aqueles que querem se aventurar pela primeira vez pelos padrões web. O princípio desse método é da recompensa. Você pode obter um grande benefício aproximando seu código dos padrões web, mesmo que não faça tudo de uma vez. Quero mostrar como você pode começar, e obter benefícios imediatos.

Limpe seu HTML

A minha primeira recomendação é que você estude CSS. Comece pela formatação básica de fonte, cor e tamanho. Isso vai te garantir código menor e produtividade maior com pouquíssimo esforço.

Assim, ao criar um item de menu, você vai evitar códigos como este:

Parceiros

Colocando no lugar:

Parceiros

Tendo no CSS:

.menu{
font-family: Arial, Helvetica, Sans-serif;
font-size: 80%;
font-weight: bold;
color:#FF3300;
}

Como você pode ver, o CSS é extremamente simples. Aprender esses quatro atributos, mais o “font-style” (para fazer itálico), é a primeira coisa que eu recomendo. É claro, isso apenas faz cócegas nas possibilidades do CSS, ainda há muito o que aprender, mas recomendo começar por aí porque é algo que você pode aprender em alguns minutos e vai te salvar muito, muito tempo. E você vai começar a ter o controle da formatação, tendo todas as definições de fonte em um único arquivo, podendo alterar, por exemplo, a qualquer momento, a fonte de todo o conteúdo ou de todos os menus do site.

O passo seguinte para limpar seu HTML é se livrar do spacer.gif, aquele gif transparente de 1 pixel que se usa para dar espaços em tabelas, e das dezenas de tabelas aninhadas. Para isso vamos começar a estudar o “box-model”.

O pulo-do-gato aqui é um atributo CSS chamado padding. O padding é a distância entre as bordas de um elemento e o texto dentro dele. Assim, se é preciso que o conteúdo de uma célula esteja a 10 pixels da borda esquerda, ao invés de inserir uma célula extra como espaçador, ou inserir mais uma tabela, basta definir uma classe para essa célula. Uma vez que você já está colocando a formatação no CSS, provavelmente esta célula já tem uma classe. Então basta:

.conteudo{
padding-left:10px;
}

Isso vai fazer com que o texto esteja a 10 pixels da borda esquerda do documento. Ah, claro, o CSS também pode livrar você de definir no HTML as bordas e o background das células de sua tabela. Lembre-se, quanto mais layout e formatação você colocar no CSS, mais controle terá sobre seu site, principalmente em mudanças de layout durante o processo de produção e em futuras manutenções. O site também será mais leve para carregar.

Concluímos então que, após aprender os atributos de formatação de fonte, o passo seguinte é aprender os atributos background, border e padding. Indo até aqui você com certeza será um desenvolvedor muito mais feliz! Depois de limpar seu HTML, ganhar controle sobre a formatação de seu site e se tornar muito mais produtivo, você está pronto para passar à segunda etapa, correndo atrás da semântica.

Começando o Trabalho de Gente Grande

Muito bem, agora você já pode limpar seu código. Vamos estudar um exemplo prático. No começo de cada uma de suas páginas você tem um título, cujo código hoje é assim:

Novidades

Ao limpar esse código, você vai substituir esse monte de tags por uma só. Que tag você vai usar? Como o CSS te permite formatar qualquer elemento, muita gente que começa a estudar o assunto acha que é indiferente que tag usar, e coloca algo como:

Novidades

Agora, veja bem, outro desenvolvedor poderia resolver o mesmo problema com:

Novidades

E o resultado visual poderia ser o mesmo. Acontece que há algo na natureza do HTML que nos diz que tag usar. Chamamos esse algo de “semântica”: as tags do HTML tem significado. A tag P é para parágrafos, a tag DIV para divisões no conteúdo, e há uma série de tags para título, h1, h2, h3, h4, h5 e h6. Assim, se você pode usar qualquer tag, pode fazer assim:

Novidades

O que você ganha com essa preocupação? Os buscadores inteligentes podem ler semanticamente o conteúdo de um documento, entendendo que trecho de código é um título, por exemplo. Assim, escrever HTML semanticamente correto pode melhorar muito sua visibilidade em buscadores. O segundo bom motivo é que você vai saber para que serve cada tag se tiver que mexer nesse mesmo documento daqui a alguns meses. E vai ser mais fácil também se outra pessoa tiver que dar manutenção no seu código.

Logo, use as tags do HTML para aquilo para o que foram criadas:

dd, dl e dt para listas de definições (um glossário, por exemplo)
h1 a h6 para títulos
p para parágrafos
abbr para abreviaturas e acronym para acrônimos
blockquote e q para citações longas e curtas
address para endereços (sabe aquele rodapé onde vai o endereço e o telefone da empresa?)
ul e ol para listas e li para os itens da lista

Você pode obter uma lista mais abrangente em:
http://www.w3schools.com/xhtml/xhtml_reference.asp

E formate tudo ao seu gosto com CSS.

Finalmente, Livrando-se das Tabelas

Não há bons motivos para você eliminar a qualquer custo todas as tabelas de seu primeiro trabalho. Conheço alguns excelentes profissionais, muito talentosos, que fizeram um ótimo trabalho em sua primeira tentativa de tableless. Mas a maioria dos que eu vi tentarem demoraram muito para conseguir da primeira vez, e alguns não obtiveram os resultados que esperavam. Isso tudo serve para que você possa produzir mais rápido e melhor, não o contrário. Então vá com calma. Faça alguns estudos em tableless, comece eliminando parte das tabelas em seus primeiros trabalhos. Por exemplo, remover as células de tabela que formam o menu, trocando por uma lista (com as tags ul e li), é um ótimo desafio para o primeiro projeto.

Ah, e não se esqueça que para dados como uma tabela periódica ou um calendário a solução semanticamente correta é a tabela mesmo. Ou seja, tableless não é ausência de tabelas, é o seu uso apenas onde é semanticamente justificável.

Não vou entrar em detalhes aqui, porque já escrevi bastante sobre como construir um layout no Tutorial Tableless Básico, mas o conselho é ir com calma, sem estresse. Você logo vai estar produzindo tableless mais fácil do que produz sites com tabelas.

XHTML

Há uma coisa que muita gente que está começando me pergunta: o que é e para que serve esse tal de XHTML? É muito mais simples do que parece. Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser. Não estamos falando de um novo HTML, com novas tags ou coisa assim. Pelo contrário, o XHTML 1 foi feito para funcionar mesmo em navegadores antigos. Mas, ao mesmo tempo, Um arquivo XHTML é também um arquivo XML válido, que pode ser lido por qualquer interpretador de XML.

Meu primeiro conselho, nesse caso, é que você, se não trabalha com XML, deixe preocupação com o XHTML para depois de dominar bem o código semântico e o layout tableless. Não porque seja complicado, pelo contrário, transformar bom HTML em XHTML é bem simples, mas simplesmente porque você pode obter benefícios muito significativos, e muito mais rapidamente, aprendendo CSS do que XHTML.

O segundo conselho é que você comece a estudar o assunto. Depois de dominar bem layouts CSS, mergulhe no XML. A maioria dos bancos de dados hoje permite extrair dados diretamente em XML e todas as plataformas de aplicações web trabalham bem com XML. E com a poderosa linguagem XSLT você pode muito facilmente oferecer seus os dados em XHTML para o navegador.

Voando Alto

Estamos falando de muito mais do que criar sites estilosos. Há duas semanas esteve aqui um amigo com um Palm novo, um Zire 71, e um celular com acesso à internet. Isso está se tornando cada vez mais barato e comum. Conheço também uma porção de empresas e instituições, entre elas uma série significativa de TeleCentros e órgãos públicos, que estão adotando Linux como sistema operacional para desktops. O Google hoje é responsável por 90% do tráfego que meu site consegue de buscadores. É o primeiro colocado absoluto entre os buscadores. E conseguiu isso indexando semanticamente o conteúdo real dos sites. Praticamente todas as plataformas web estão oferendo suporte a XML e apostando na idéia de webservices.

Quem segue os padrões web não precisa ter medo do futuro. Não importa que browser vai ser o mais usado daqui a dois anos, que tecnologia vai estar na moda ou de onde as pessoas vão estar usando a internet. Seu site estará lá, leve, acessível, atual e útil.

Posts Relacionados

Mobilidade na cabeça

Diego Eis — Wed, 10 Jan 2007 16:26:16 +0000

Ontem, depois do lançamento do iPhone e de ter visto suas funcionalidades (nem tão novas assim, mas reinvatadas de verdade), fiquei pensando em uma funcionalidade em particular: navegação na internet. Quem assistiu o Keynote viu o camarada navegando de verdade com um browser de verdade (Safari) e tendo uma experiência realmente boa. O browser carrega o site inteiro, lendo XHTML e CSS, nada de SSR ou qualquer coisa parecida e é renderizado como se fosse uma miniatura na tela, mas a formatação é integral, como se estivesse sendo visualizado de um desktop. Sim, ficou impossível de ler, mas isso foi resolvido quando o nosso camarada tocou duas vezes no lugar que ele gostaria de ler e o browser deu um ZOOM, possibilitando a leitura.
Essa experiência é muito comum hoje em dia, só que em vez de dedos, você estaria usando uma Stylus (aquela canetinha nojenta), muito pior de manejar do que seus dedos.

A impressão que eu tive sobre a experiência de navegação no iPhone é ótima. Será um dispositivo que os desenvolvedores não terão que se preocupar com compatibilidade, você nem vai precisar fazer uma versão especifica para mobiles (no caso do iPhone). Sim! Você ainda precisa se preocupar com desenvolvimento de sites para dispositivos móveis. O iPhone não é o único dispositivo do mercado, infelizmente.

Também hoje, o Yahoo! liberou para download um pacote de programas direcionados para celulares. O Yahoo! sempre foi antenada quando se trata de mobiles. E você sabe que eles fazem um trabalho bem feito. Sem comentar do Opera, que é um dos melhores (ou melhor) browsers para dispositivos móveis que existe.
Mobilidade é uma coisa que todo mundo precisa e quer. Quem tem um celular hoje, não consegue mais viver sem. Quem tem um celular com conexão à internet também não consegue viver sem. E assim o público vai mudando e se inovando. Aí é onde a coisa fica mais interessante.

Já falei e repito: pra mim, este ano será da mobilidade. Haverá mais interesse nesse mercado, mais procura, mais agitação. Se as empresas acima estão dando uma certa atenção pra isso, já é motivo para mexermos nossos ossos e corrermos atrás do prejuízo desde agora.

Posts Relacionados

Breve introdução: XHTML Mobile Profile

Diego Eis — Tue, 28 Mar 2006 03:01:11 +0000

XHTML MP é um subset do já conhecido XHTML. Ele é baseado em um outro subset de XHTML chamada XHTML Basic. O XHTML Basic é uma versão simplificada do XHTML definido pelo W3C. Ele foi feito especificamente para dispositivos com baixo poder de processamento como celulares, PDAs, pagers etc… O XHTML Basic não contém algumas características que esses dispositivos dificilmente suportam, como por exemplo: Frames, Folhas de Estilo em Cascata e scripts.

O ponto forte do XHTML MP é trazer para os dispositivos móveis tecnologias atuais para criar uma experiência melhor ao navegar. Antes do nascimento do XHTML MP, os desenvolvedores para internet móvel usavam WML e WMLScript para criar sites em WAP. Enquanto isso, os desenvolvedores para a internet convencional trabalhavam com HTML/XHTML e CSS para construir web sites.

Com a vinda do XHTML MP, a linguagem da internet sem fio e a linguagem da internet convencional finalmente convergiram. XHTML Mobile Profiles juntamente com o WCSS deram mais flexibilidade para os desenvolvedores de sites para dispositivos wireless. Agora, desenvolver para dispositivos móveis ficou tão fácil quanto desenvolver web sites normais. Não é mais necessário ter dispositivos ou softwares especificos para testar seu projeto. Não é mais necessário aprender outra linguagem, é tudo XHTML e CSS, claro, com mudanças específicas para mobiles.

Assunto interessante. Dá muito pano para manga.
O texto não está tão elaborado porque é um rascunho sobre algumas coisas que ando lendo. Como não tive tempo de fazer um texto mais completo, acabei postando esse mesmo.

obs.: quase uma tradução do texto que está em XHTML MP. E uma prévia para breves lançamentos na Visie.

Posts Relacionados

Principais pontos da Acessibilidade na Web

Diego Eis — Wed, 01 Feb 2006 10:00:21 +0000

Quando ouvimos falar de sites acessíveis, logo imaginamos sites que podem ser acessados por pessoas com necessidades especiais. Isso é um grande erro que não podemos cometer. Ao termos essa atitude, negligenciamos uma série de outros fatores que são extremamente importante para a boa acessibilidade do site.

Abaixo, vamos tentar resumir os principais pontos que a Acessibilidade na Web alcança.

Diversos Dispositivos

Hoje o meio mais comum de navegar pela Web é usando um Desktop, ou seja, um Computador pessoal. Mas de uns tempos para cá, essa realidade vem mudando.

Os dispositivos móveis estão sendo muito difundidos e com isso ganham mercado entre os usuários. Hoje, em shoppings, aeroportos e outros lugares com alguma conexão sem fio, já podemos ver pessoas acessando a internet com variados Handhelds.

Há também o surgimento das WebTV´s e outros aparelhos semelhantes que permitem o usuário acessar a internet, usando um aparelho de televisão como dispositivo de saída.
Não é só a TV que ganhou a conexão com internet, microondas e geladeiras também foram privilegiadas. Com o tempo, isso se tornará cada vez mais comum.

A tendência é que cada vez mais surjam novos dispositivos acessando a web.

Diversas Plataformas

Quando você ouve sobre diferentes plataformas, alguns nomes lhe vem na cabeça, como Windows, Linux ou MacOS. Esquecemos de que os HandHelds, Tables ou outros dispositivos, usam seus próprios Sistemas Operacionais. O Palm por exemplo usa o PalmOS, o PocketPC usa Windows Mobile e a Internet Tablet Nokia 770, usa um sistema baseado em Gnome e Linux.

O que quero dizer, é que muitos desenvolvedores, ao fazer algum sistema para internet, usam algum tipo de sistema proprietário, favorecendo apenas uma plataforma. O pior, é que nenhuma versão alternativa é disponibilisada, restringindo muitos usuários.

Diferentes Browsers

Atualmente, os fabricantes de browsers, estão tendo um certo cuidado com a abordagem de padrões do W3C e plugins de terceiros.
Mas, infelizmente, muitos desenvolvedores ainda fazem a implementação dos sites se guiando pela metodologia antiga.

A Abordagem dos padrões é extremamente importante para que haja um nível de compatibilidade aceitável, não só entre navegadores de uma mesma plataforma, mas principalmente, entre navegadores de outros dispositivos. Usando metodologia antiga, site fatalmente necessita de uma versão para handhelds. Já um site que foi construído baseando-se nos Web Standards, fica melhor acessível mesmo não havendo uma versão especifica para esses dispositivos.

Todas as Pessoas

Atualmente, o acesso à internet por pessoas com algum tipo de deficiência física cresceu absurdamente. Os leitores e sintetizadores de tela também melhoram muitos seus sistemas. O que ainda continua parado, é a maioria dos sites que não atentam para pequenos detalhes que melhorariam muito a navagabilidade desses usuários.

Existem robôs que avaliam o nível de acessibililidade tem seu site. Eles te dão sugestões e te mostram alguns aspectos que devem ser levados em consideração.

A Acessibilidade na web é um assunto muito amplo, e que deve ser estudado com certo interesse pelos desenvolvedores.