Desenvolvimento de Aplicações para Web

Alt, Text e Tool Tip

2011-03-03T15:24:00.000-08:00

Tool Tip é um elemento gráfico de interface, uma pequena caixa de texto que aparece quando pausamos o ponteiro do mouse, por um segundo ou dois, por sobre uma imagem (ou objeto), sem clicá-la, contendo uma breve informação sobre a imagem (ou objeto) em questão.

Bem há pouco tempo, até o lançamento da versão do Internet Explorer 8 (IE8) em 19 de março de 2009, havia uma certa confusão entre os desenvolvedores web a respeito de qual elemento HTML usar para implementar o tooltip, se este deveria ser o atributo ALT ou o TITLE. Para que o tooltip funcionasse corretamente em vários navegadores, muitos desenvolvedores chegaram ao cúmulo de descrever o mesmo conteúdo nos dois atributos, apesar deles servirem a propósitos diferentes. Essa confusão ocorreu devido o fato de que, até a versão 7 do IE, inclusive, o atributo ALT era usado para implementar o tooltip e não o atributo TITLE, como deveria ser.

Segundo a Especificação HTML 4.01, o atributo ALT especifica um "texto alternativo que serve de conteúdo ao elemento, sempre que este não poder ser exibido normalmente". Ou seja, o texto declarado em ALT deve ser apresentado no lugar da imagem (ou objeto) sempre que esta não puder ser visualizada pelo navegador.

No mesmo documento, com relação ao atributo TITLE, é descrito que "os valores deste atributo (title) poderão ser representados pelos agentes de variadas formas. Por exemplo, os navegadores visuais exibem, frequentemente, o título sob a forma de "tooltip"...". Ou seja, cabe ao atributo TITLE a implementação do tooltip. Este bug só foi corrigido a partir do IE8, mas infelizmente a confusão já estava criada.

Portanto, use o atributo ALT somente para especificar textos alternativos para quando as imagens não puderem ser exibidas. Inclusive o uso deste atributo é recomendado como uma forma de melhorar ou implementar acessibilidade de um site (Directiva 1 - Fornecer alternativas ao conteúdo sonoro e visual). Se, no entanto, você quiser fornecer informações suplementares a respeito de uma imagem (ou objeto) na forma de tooltips, use, então, o atributo TITLE.

Referências:

Uso do charset nas páginas web

2008-11-04T07:15:00.000-08:00

Um charset ou character set consiste em uma combinação de bits/bytes (codificação) usada para expressar um conjunto de caracteres ou símbolos gráficos (repertório) que serão exibidos e/ou impressos em um sistema computacional específico. Em termos práticos, um charset é uma tabela de valores inteiros que faz o mapeamento para um conjunto abstrato de caracteres e/ou símbolos gráficos e que descreve o método de conversão de uma seqüência de octectos (8 bits) em uma seqüência de caracteres e vice-versa (RFC 2978).

Durante alguns anos um conjunto de caracteres de 7 bits (ou 128 caracteres) conhecido como tabela ASCII foi empregado e ainda continua sendo usado em muitos sistemas computacionais. Porém, dada a variedade de línguas, caracteres e símbolos gráficos, a tabela ASCII tornou-se insuficiente para representar todo o conjunto de caracteres usados em um sistema de informações de tamanho global como a web, por exemplo. Daí a necessidade da criação e a existência não só de um outro conjunto, mas de vários outros conjuntos, maiores e mais completos, para serem usados em escala global.

Charset padrão dos documentos HTML
Um documento HTML é na verdade uma seqüência de caracteres de um dado repertório ou charset. Por ser usado em escala global, todo documento HTML emprega um conjunto de caracteres mais completo de 32 bits (ou 4 bytes) conhecido como UCS (Universal Character Set ou ISO-10646), padrão equivalente ao conjunto UNICODE. Disso resulta que os navegadores e editores HTML utilizam internamente o ISO-10646 como padrão. Este conjunto define um repertório de milhares de caracteres (96.447 na versão 4.0) que é usando por todo o planeta.

Entretanto, o esquema de mapeamento de um conjunto abstrato de caracteres para uma seqüência de bytes (octetos), também conhecido como Esquema de Codificação de Caracteres (Character Encoding Scheme ou CES), do padrão ISO-10646 não é compatível com muitas aplicações atuais. Para resolver esse problema, foram criados outros formatos que são aplicáveis somente ao padrão ISO-10646, dentre eles o UTF-8, padrão mais utilizado em documentos HTML.

Definindo o charset de um documento HTML
Para que o charset empregado em um documento HTML funcione corretamente é preciso ficar atendo aos seguintes fatores:

a) A língua:
Para o nosso português (Brasil), o padrão adotado é o ISO-8859-1 (Alfabeto latino 1). Normalmente, é bom declará-lo junto com a definição da lingua ('pt-BR') no documento .

* Usando o atributo LANG
<html lang="pt-BR"><head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> ...

ou, então,

* Usando o elemento META
<html>
<head>
<meta http-equiv="Content-Language" content="pt-BR">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> ...

Obs.: Os elementos META também podem ser redefinidos/redeclarados através do servidor web, sendo ou não declarados no HTML.

b) O editor de texto.
Muitos editores de texto do Windows trabalham internamente com o padrão windows-1252, padrão não-ISO incompatível com os padrões ISO-8859-1 e UTF-8. Isso pode ocasionar alguns problemas quando as páginas, usando esse padrão, forem visualizadas pelos browsers. Por exemplo, se os caracteres acentuados em português forem declarados através de Referência Caracter Numérica (NCR – Numerica Character Reference: representação no formato "&#D;", "H;" ou "&#nome_entidade;" disponível no padrão HTML 4.01 que faz referência a um conjunto limitado de caracteres da tabela UNICODE, usando apenas o conjunto de caracters ASCII comum a todos os charsets), de modo geral, não haverá muitos problemas, porém se a acentuação for feita diretamente no documento HTML, os browsers só conseguirão visualizar corretamente as páginas se adotarem o mesmo charset usado pelos editores windows, ou seja o windows-1252. Como o padrão da maioria dos browsers é UTF-8, provavelmente muitos usuários terão algum problema em visualizar essas páginas.

É muito comum iniciantes em programação HTML editarem o documento HTML usando (sem saber) o padrão windows, declarando o charset do documento como ISO-8859-1 (padrão latino 1) e, para complicar ainda mais, o usuário visualize a página usando o padrão UTF-8. Conclusão: ao final de tudo, a página acaba não sendo visualizada corretamente e apresenta um monte de caracteres esquisitos na tela do browser.

c) O banco de dados.
Os dados armazenados em um banco de dados também são codificados usando um charset específico, definido no momento da criação do banco. Por isso, deve-se estar atento para que o mesmo conjunto de caracteres empregado nas páginas seja o mesmo usado no banco, para não haver incompatibilidade entre eles. Quando isso ocorre, deve-se aplicar um conversor nos dados do banco antes deles serem exibidos nas páginas.

Conclusão

Antes de começarmos a construir um documento HTML é preciso definir qual o charset será utilizado: UTF-8 ou ISO-8859-1;
Visto que o charset UTF-8 é padrão nos documentos HTML, podemos optar por ele no lugar do ISO-8859-1;
Para outras línguas não-latinas (japonês, chinês etc) é preciso especificar o charset adequado à língua empregada no documento HTML;
É preciso unificar todos os ambientes/sistemas em um único charset: documento HTML, editor e BD. Se a unificação não for possível, deve-se buscar soluções onde um conjunto de caracteres de um seja convertido para o outro.

Resolução de páginas web

2007-05-24T09:22:00.000-07:00

Muito tem sido discutido a respeito de qual largura devemos usar ao desenvolvermos uma página. A área útil de um browser, ou seja, a área realmente aproveitável em que visualizamos a página é extremamente variável e depende do hardware e dos softwares empregados (resolução de vídeo; sistema operacional; barras superiores e laterais visíveis/ocultas; tamanho dos botões; janela minimizada ou não; o próprio browser; etc). Por exemplo, numa resolução de 800x600 podemos ter uma área útil que pode variar de 762~796x410~439, dependendo da configuração e do equipamento do usuário.

Não existe uma resolução padrão que atenda a tudo e a todos. É preciso estabelecer no início do projeto um padrão de resolução mínimo desejado e trabalhar em cima disso. Conhecer o perfil do público-alvo auxilia bastante nessa decisão. Porém na falta de informações, procure atender ao maior número de pessoas possível. Vários sites de pesquisa (IBOPE, ebitEmpresa, etc) oferecem diversas estatísticas a respeito deste assunto e muito mais. O que se observa é que a resolução de 640x480 deixou de ser utilizada já há algum tempo e que a resolução de 800x600 vem aos poucos dando lugar para a de 1024x768 (veja a tabela abaixo). Por enquanto, trabalhar com uma área útil de 760x410 para uma resolução de 800x600 ainda tem sido uma boa decisão. Entretanto, devido a facilidade com que se tem hoje em adquirir monitores de tamanhos e resoluções maiores, este perfil vem mudando.

	Junho 2005	Dezembro 2005	Junho 2006
800x600	55,8%	49,4%	44,2%
1024x768	38,4%	43,1%	47,2%

Tab1. – Resolução de monitor utilizada por e-comsumidores.
Fonte: Grupo de pesquisa e-bit (www.ebitempresa.com.br)

O conceito de Layout “líquido” (layout em que as dimensões de uma página usam tamanhos percentuais ou proporcionais de modo a se adaptar as dimensões da janela do browser) é uma forma de fazer com que o conteúdo de uma página se adapte a várias resoluções (dê uma olhada como isso funciona em www.useit.com). Este conceito é muito bem aplicado quando trabalhamos numa faixa de valores limitada. Fora destes limites, conforme as dimensões da janela diminuem, os elementos gráficos podem começar a perder detalhes a ponto de tornarem-se irreconhecíveis, prejudicando o layout. Da mesma forma, os outros elementos da página (texto, tabelas, estruturas, listas, etc) podem ficar de tal modo comprimidos que a leitura e a visibilidade tornam-se prejudicadas. Algo parecido também ocorre quando as dimensões aumentam muito. Os elementos podem tornar-se muito dispersos a ponto de deixarem espaços vazios na página.

O emprego do CSS auxilia bastante no desenvolvimento da página e soluciona em parte o problema de resolução. Para um mesmo conteúdo, podemos desenvolver diferentes layouts para diferentes mídias (screen, print, handheld, etc). Entretanto, o layout deve ser adaptado e preparado para cada uma delas. Além do mais, o CSS por si só não é capaz de identificar a resolução usada e adequar o layout para esta resolução. Isto envolve uma programação um pouco mais rebuscada que pode ser implementada tanto no lado servidor quanto no lado cliente ou em ambos. É preciso um pouco mais de trabalho que no pior dos casos poderá utilizar diversas tecnologias ao mesmo tempo: layout líquido, CSS, javascript, SSI, etc.

Exemplo de código HTML que veicula um layout específico em CSS
para ser aplicado em dispositivos de impressão.

Com o surgimento e o aumento dos dispositivos móveis (palms, handhelds, celulares, etc) com acesso a Internet essa decisão torna-se ainda mais complicada e exige um pouco mais de trabalho e planejamento. A maioria das páginas é desenhada para serem visualizadas em computadores e podem não se adequar bem a estes dispositivos. A revista www.com.br, n° 79 de Fev/2007, tem uma matéria específica sobre o assunto e fala exatamente sobre o desenvolvimento de páginas para dispositivos móveis. Uma outra fonte de informação disponível sobre tema é o documento "Mobile Web Best Practices 1.0" (www.w3.org/TR/mobile-bp) publicado pela W3C.

Boa leitura e até mais. ";^)´

Quem nunca recebeu um código 404 que atire a primeira pedra

2007-05-14T05:31:00.000-07:00

A Internet é uma maravilha, passamos horas navegando nela sem sentirmos o tempo passar e, por mais incrível que pareça, quando mais tempo ficamos, mais nos desvirtuamos do assunto que estávamos inicialmente procurando. Chamam isso de “surfar na net”, um bonito nome para dizer que viajamos em pensamento, só que agora com o auxílio de um computador e uma rede de acesso a Internet.

Pois bem, outro dia estava eu surfando pela net e para não deixar de ser diferente, comecei com uma pesquisa e fui parar em outro lugar, acessando outro assunto completamente diferente (é interessante como dispersamos o pensamento enquanto surfamos!). Acabei achando um site com temas interessantes que eu procuro já faz um tempo. A primeira coisa que nos vem é aquela sensação de que acabamos descobrindo um grande tesouro, um veio de ouro ou uma pedra preciosa no meio do nada. Uau! Agora entendo porque um garimpeiro passa os diabos e ainda continua garimpando. Qual não deve ser a sua sensação após dias de procura e sofrimento (fome, mosquitos mordendo, malária, sem banho, etc) e, depois disso tudo, achar uma pepita de ouro ou uma linda ametista em seu estado bruto? Até vejo aquele pobre coitado pulando feito macaco, sem dentes na boca e gritando: “Achei, achei! Tô rico!”.

Bem, voltando aquele site que eu encontrei, estava eu tomado de tamanha euforia e na companhia do meu navegador e amigo inseparável Firefox, que eu comecei alucinadamente a clicar em vários links e abrir páginas e mais páginas dos mais diversos assuntos nas várias abas do navegador (só agora a Micosoft se deu conta da importância das abas num navegador!). De repente, aquele banho de água gelada me cai na cabeça e percebo que as páginas que eu abria só retornavam o código 404. Para quem não sabe, o código 404 (Not found! – não encontrado!) aparece quando fazemos requisições a páginas que não existem mais em um site. Se você ainda não recebeu uma mensagem com 404, não se preocupe. Você é um felizardo e pode atirar a primeira pedra. Quem sabe também não aproveita para fazer uma fezinha na loteria, tamanha a maré de sorte.

Este problema normalmente ocorre quando erramos ao digitamos o endereço no navegador (o que é muito comum!) ou quando (não deveria ser tão comum assim!) o infeliz do webmaster (você sabe! Aquele que deveria cuidar do site e evitar isso.) não está fazendo o seu trabalho direito e não verificou a existência de links quebrados (links que apontam para páginas que não existem mais).

Pior do isso, são aquelas páginas com 404 disfarçado. Sabe aqueles sites com a mensagem “Página em construção” normalmente feito pelo sobrinho do amigo do amigo de um amigo meu (adolescente inteligente "para mais de metro", orgulho de toda a família!) que aprendeu a fazer páginas HTML, seguindo dicas que encontrou numa apostila de mil novecentos e antigamente, auxiliado por um programinha gratuito que vinha dentro do CD de uma revista de hackers? Pois é, só de pensar que existem um monte de páginas assim me dá uma baita dor de cabeça! Apesar de banho gelado ser recomendado em casos de enxaqueca, me senti frustrado em minhas intenções. Se você acha que estou exagerando, experimente fazer uma busca com a palavra “Página em construção”, só eu achei nada mais que 2.670.000 delas. Se está em construção (ora pois!), não deveriam nem aparecer e nos poupar o tempo, o trabalho e a decepção em encontrá-los.

Aliás, o assunto que eu buscava e me interessava acabei não encontrando, só deu 404. Enfim, depois disso tudo que passei, só me restou duas coisas a fazer: desistir da busca (é claro!) e escrever esta crônica só para desabafar um pouco!

Criando âncoras nomeadas com ID ou NAME ?

2007-04-25T12:14:00.000-07:00

Na especificação HTML 4.01, uma âncora nomeada pode ser criada usando tanto o atributo NAME quanto o ID. Porém, versões mais antigas de alguns navegadores não possuem suporte a âncoras nomeadas criadas pelo ID. Quando isso acontece, os links que apontam para essas âncoras simplesmente não funcionam.

Para os elementos HTML (p. ex. A, APPLET, etc) que permitem a declaração de ambos atributos (ID e NAME), uma solução simples e prática seria definir os dois ao mesmo tempo:

Isso resolveria em parte o nosso problema, mas não funcionaria para os demais elementos do HTML (a maioria deles) que não possuem o atributo NAME. Uma outra solução seria criar uma âncora nomeada separadamente, usando o elemento A com os dois atributos declarados.

Assim, por exemplo, a declaração de âncora:

poderia, então, ser substituída por:

Diferente do NAME, o atributo ID pode assumir outras funcionalidades além da criação de âncoras nomeadas: seletor de folha de estilos, identificador de processamento, etc. Para esses casos, uma solução seria desvincular as funcionalidades, usando nomes diferentes para identificar cada uma delas.

Por exemplo, a codificação abaixo possui duas funcionalidades (âncora e seletor CSS):

ela poderia ser reformulada e substituída, então, por uma nova codificação, separando as duas funcionalidades:

resolvendo definitivamente o nosso problema de criação de âncoras através ID ou NAME.

":^)'

Esquentando os motores com o briefing

2007-04-16T06:38:00.000-07:00

“Para quem não sabe onde chegar, qualquer caminho serve” (Provérbio Chinês).

Todo desenvolvimento de um site começa com uma idéia ou surge de uma necessidade qualquer. Pode ser, por exemplo, o lançamento de um novo produto e/ou serviço, ameaça da concorrência, necessidade de expandir mercados, racionalização de processos, etc. Seja qual for o motivo, se um cliente vai até você é porque ele tem um problema que o está incomodando e que precisa ser resolvido.

Antes de se iniciar qualquer trabalho é preciso reunir conhecimentos a respeito do seu cliente, seus problemas, o ramo de seu negócio e das suas atividades. Este processo é conhecido como briefing. O briefing nada mais é que um documento onde são descritos os desejos, anseios e expectativas dos clientes em relação a um dado projeto.

É claro que existem bons projetos desenvolvidos sem um briefing. Assim como há também casos em que o cliente não sabe realmente o que quer ou o que está procurando, podendo em algumas vezes ter até uma visão distorcida do problema. Seja como for, uma coisa é certa: um planejamento feito de forma consistente e estruturada torna-se uma ferramenta indispensável que, quando bem elaborado, aumenta as possibilidades do seu projeto ou plano de ação dar certo, independente do tamanho do trabalho e da área envolvida.

Um briefing bem feito é fundamental pois ele aponta um caminho e define algumas metas alinhadas com os interesses do seu cliente ou negócio. Além disso, podemos identificar riscos e oportunidades, saber um pouco mais sobre a concorrência, conhecer as estratégias e planos de ação da empresa, restrições e resistências ao projeto, experiências do cliente e expectativas em relação ao trabalho, etc. É fundamental conhecer o meio onde você irá atuar. Quanto mais informações obter sobre este meio, melhor. Com base nelas é que serão tomadas algumas decisões de projeto que irão determinar ou não o sucesso de todo um trabalho.

Apesar de parecer ser simples, elaborar um briefing não é uma tarefa fácil e/ou trivial. A margem de erro deve ser a menor possível pois além das informações estratégicas e técnicas necessárias, devemos levar em consideração os problemas de comunicação, aspectos pessoais, sociais e psicológicos envolvidos, interesses, resistências, etc.

Enfim, para a facilitar um pouco mais este processo, deixo aqui uma proposta para elaboração de um briefing que espero o ajude e sirva de pontapé inicial. Além disso, procure se informar mais sobre o assunto em livros e revistas especializadas. A edição 39 da revista Webdesign (março de 2007), por exemplo, possui uma matéria muito interessante sobre o assunto, não deixe de ler.

A primeira vez a gente nunca esquece!

2007-04-04T09:39:00.000-07:00

Esta é a primeira vez que escrevo para um blog e garanto como toda primeira vez a gente rateia, engasga, derrapa, gagueja, .... Enfim, se você se esqueceu como é, basta se lembrar do seu primeiro beijo. A gente se pergunta mais do que propriamente executa o ato: "Ponho ou não ponho a língua?", "Ai meu Deus! O que esta língua esta fazendo na minha boca?", "Nossa! Isto tá esquentando ou é só impressão minha?" e por aí vai.

Começar algo novo (como este blog por exemplo!) é como começar a dirigir um carro. Sabemos que temos de pisar na embreagem até o fim, passar a primeira, acelerar um pouco o motor, soltar a embreagem lentamente e, conforme o carro começa a andar, vamos acelerando ao poucos até soltarmos de vez a embreagem. Porém, a realidade da primeira vez é outra: o motor morre, a marcha pula, o volante trava, o carro sai pipocando, o motor afoga e não liga mais, o carro não pega embalo, arranhamos a marcha, encostamos sem querer na buzina, colamos a cara no vidro da frente, emaranhamos com o cinto de segurança, etc. É uma tragédia só!.

Para não fugir a regra, estou começando a escrever para este blog e espero que com o tempo e bastante treino eu consiga atender ao tema proposto: "Desenvolvimento de Aplicações para a web". Enquanto isso, deixa eu ligar o carro e treinar a primeira marcha.
Nos vemos mais tarde!
[]´s ":^)'