Webpoint
Weblosofia com CSS, Jquery, Javascript, Ajax, PHP etc.
por Alexandre Magno
Categorias
- Ajax
- Browser
- Bugs IE
- CSS
- Experiência do usuário
- Ferramentas
- Frameworks Js
- Javascript
- Jquery
- jQuery avançado
- jQuery UI
- Melhores práticas
- Mootools
- PHP
- Plugins
- Programas
- projetos jQuery
- Receitas CSS
- SEO
- SWFUpload e Jquery
- Usabilidade
- W3C
- Weblosofia
Arquivos
- Junho 2009
- Abril 2009
- Março 2009
- Fevereiro 2009
- Janeiro 2009
- Outubro 2008
- Julho 2008
- Abril 2008
- Março 2008
- Janeiro 2008
- Novembro 2007
- Setembro 2007
- Agosto 2007
- Julho 2007
Links
- CSS para Webdesign
- A list apart
- Maxdesign
- Tableless
- Poisition is Everything
- Blog do tmferreira
- Pensamento Web
- Jquery Brasil
- Julio Greff
- Túlio Faria
- Rafael Marin
- Ajaxian
- Quirks mode
- Igor Escobar
- Pinceladas da Web
- Juareznjunior’s Weblog
- TidBits
- Tales Augusto
- Roberto Brasileiro
Calendário para jQuery em português
Postado em 18/06/2009 por Alexandre Magno
Ler comentários (Nenhum comentario)
Há um tempo atrás escrevi um post do plugin jCalendar em português. Ele é bastante visitado e gostaria muito de oferecer uma solução atual para este plugin usando o próprio jQuery. Muito tempo passou e atualmente existem soluções melhores para ter uma ferramenta de escolhas de datas. o jQuery UI veio como uma luva para unificar plugins de interface e um dos seus componentes é o Datepicker. Com ele, você pode configurar um calendário para funcionar no formato nacional apenas passando as configurações adequadas, sem modificar o core.
Para utilizá-lo, é necessário fazer o download no site do jQuery UI. Esta biblioteca de plugins possui vários outros plugins que irei tratar no futuro, portanto se for utilizar mais alguma por conta própria baixe o pacote completo, caso contrário somente o plugin datepicker e o core do jQuery UI.
Após inseri-lo no head do documento, basta ter um simples input referenciado de alguma forma, preferencialmente id, para que ele possa ser acessado via seletor do jQuery e assim inicializado como no exemplo:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>jQuery Date picker</title> <script type="text/javascript" src="jquery-1.3.2.min.js"></script> <script type="text/javascript" src="jquery-ui-1.7.2.custom.min.js"></script> <script type="text/javascript" src="calendario.js"></script> <link rel="stylesheet" type=text/css href="jquery-ui-1.7.2.custom.css" /> </head> <body> <form action="/" method="post"> <label for="calendario">Data:</label> <input type="text" name="calendario" id="calendario" /> </form> </body> </html>
O arquivo calendário.js contém o seguinte conteúdo:
$(function(){
$("#calendario").datepicker({
dateFormat: 'dd/mm/yy',
dayNames: [
'Domingo','Segunda','Terça','Quarta','Quinta','Sexta','Sábado','Domingo'
],
dayNamesMin: [
'D','S','T','Q','Q','S','S','D'
],
dayNamesShort: [
'Dom','Seg','Ter','Qua','Qui','Sex','Sáb','Dom'
],
monthNames: [
'Janeiro','Fevereiro','Março','Abril','Maio','Junho','Julho','Agosto','Setembro',
'Outubro','Novembro','Dezembro'
],
monthNamesShort: [
'Jan','Fev','Mar','Abr','Mai','Jun','Jul','Ago','Set',
'Out','Nov','Dez'
],
nextText: 'Próximo',
prevText: 'Anterior'
});
});
Ao passar as configurações acima o calendário se torna totalmente formatado para a forma nacional, simplesmente passando estes parâmetros. Há outras formas de personalização, como a faixa de anos exibida e outras configurações que pode ser consultadas na documentação. Os itens do exemplo acima são bastante auto-explicativo.
O estilo pode ser personalizado no arquivo css que vem junto com o plugin e o jQuery UI tem conceito de temas. Você pode escolher um tema para ele que adeque mais a sua situação, tão bem como criar um personalizado apenas modificando o CSS.
Utilizando fontes alternativas sem ferir a semântica
Postado em 02/06/2009 por Alexandre Magno
Ler comentários (Nenhum comentario)
Já tem um tempinho que não escrevo nada no Blog. Estava realmente muito ocupado tanto como tempo tanto com a cabeça por causa da recente mudança para o Rio de Janeiro, cidade realmente maravilhosa, mas meu amor por Belo Horizonte ainda permanece. O motivo da mudança é que agora estou trabalhando no desenvolvimento de interfaces na Globo.com, mas os detalhes ficam para outra oportunidade! Estava ansioso para escrever sobre o assunto que irei tratar aqui.
O assunto posso dizer que é polêmico e apesar de serem simples algumas soluções, existe um leque de opções. Qual a melhor forma de utilizar fontes que não sejam padrão do sistema operacional e dos browsers sem prejudicar a marcação, SEO, acessibilidade, mobilidade e outros fatores?
Não existe um padrão para solucionar este problema, não existe uma forma perfeitamente adequada, que não quebre nenhum paradigma, no entanto uns ferem os princípios mais que outros. Todos os métodos existentes hoje são apenas uma aproximação da situação ideal. O fato é que cada um tem suas vantagens e desvantagem e a finalidade deste post é expor estes pontos.
Para quem não entendeu até agora o que estou dizendo, vamos a um exemplo prático. O designer faz um layout maravilhoso sem te consultar. O cliente aprova e você desenvolve a interface utilizando HTML, CSS e interações Javascript. O cliente pergunta: Por que as fontes estão diferentes do layout? Você preocupou-se com a manutenção, a marcação e utilizou puramente as três tecnologias em perfeita harmonia para não ter que ser fiel ao layout e simplesmente recortar cada imagem que represente um título.
Por que isto acontece?
Os browsers possuem uma leitura de fontes totalmente limitadas. Além disto, ele depende do sistema operacional e da plataforma onde o site é aberto. A escolha das fontes podem ser feitas através do CSS. Mesmo assim, é impossível certificar que o usuário final verá da forma como você. Do ponto de vista de padrões de acessibilidade, qualquer título ou representação textual devem estar com a semântica correta. Cada elemento tem seu significado. O problema é que muitos desenvolvedores pensam somente no resultado final, sem levar em conta a qualidade. Portanto, se você deseja ou foi solicitado a usar fontes que não sejam padrão do sistema, é necessário fazer certas opções e sacrifícios. Parece uma decisão fácil, mas não é.
Na teoria, não seria necessário recorrer a nenhuma delas e utilizar fontes de sistema, na maioria das vezes ele supre as suas necessidades como desenvolvedor e do cliente também. No entanto, muitas vezes o apelo visual é necessário, mas vale lembrar que utilizar fontes não convencionais deve ser somente utilizado para títulos, pois para textos mais longos necessitam de fontes simples e legíveis, pois é para isto que o seu texto está na web: disponibilizar conteúdo.
As várias soluções irei listar aqui:
Opção 1 - Recortar títulos como imagem
Esta opção está longe de ser a melhor. Você recorta o texto desejado no layout e insere diretamente na página na tag img.
Ela não possui nenhuma vantagem, primeiro por que você estará inserindo na marcação uma imagem para representar um texto, quebrando a semântica. Segundo por que é difícil dar manutenção e implementar isto em um sistema em que seja necessário modificar estes texto. Neste último caso será necessário gerar outra imagem manualmente para modificar o site em questão. Além disto o texto não é selecionável. É irritante a experiência do usuário de não conseguir fazer uma tarefa básica: copiar um texto em um browser.
sIFR
Este método, que significa Scalable Inman Flash Replacement, une Javascript, Flash e CSS para que a fonte seja renderizada corretamente em qualquer browser. Basicamente você escreve normalmente o html e através de javascript o texto é substituído por um SWF que renderiza a fonte. Isto acontece por que o flash não possui limitações para renderizar fonte, basta ter o arquivo enviado para o servidor e referenciado corretamente.
A vantagem é que o código é totalmente não-obstrusivo, mas cada título usado possui um swf correspondente e a perfomance pode ser muito "cara" para simplesmente exibir um título com fonte que não seja de sistema. Esta é uma grande desvantagem. Para equilibrar, temos a vantagem dos textos serem selecionáveis, graças a esta opção que o flash possui para que os textos possam ser copiados e colados.
Opção 3 - Importação através de CSS
A importação de fonte através de CSS, muito bem explicada neste artigo do Maujor, é uma técnica bastante atraente mas que ainda irá depender do comportamento do browser. Você pode ter qualquer tipo de fonte que não seja padrão, mas a sua renderização pode variar de browser para browser.
Ela consiste em usar uma ferramenta para gerar arquivos de fontes que você deseja utilizar que possa ser referenciada e importada através do CSS, utilizando uma propriedade @font-face. Nem todas as fontes são "importáveis".
Opção 4 - Utilizando a propriedade text-ident do css com um valor extremamente alto
Essa opção é muito utilizada e consiste em utilizar o css para identar o texto com um valor muito alto (negativo) de forma que não seja possível visualizá-lo e assim utilizar background-image para posicionar a imagem que representa o texto.
Temos aqui um exemplo da marcação
<h2>Titulo a ser substituido</h2> <p>lorem ipsum</p>
Então no CSS correspondente:
h2 {
background-image: url('titulo.gif');
text-ident: -999;
overflow: hidden;
}
A regra overflow hidden é utilizada para que o texto "deslocado" não apareca no site, neste caso iria gerar um scroll horizontal e resultados imprevisíveis, portanto ela é estritamente necessária para que este método funcione. Ele é muito útil para casos em que há a necessidade de garantir que nenhum resultado imprevisível "quebre" um box.
Muitas vezes também é usado uma variação deste método que ao invés de deslocar o texto, o atributo font-size é passado para o tamanho menor possível, como 0.00001 para tornar-se imperceptível.
Bem, este método tem a vantagem de deixar a marcação limpa e não prejudica a perfomance. Poderia citar a desvantagem da dificuldade da manutenção, mas nada que um script de servidor como a biblioteca GD do PHP para tornar a geração de imagens dinâmica e criar estas regras css para automatizar este trabalho. A desvantagem é que o texto não pode ser selecionado, mas a marcação permanece correta.
Sem querer insultar quem a usa, e instigando uma discussão, este método soa como "gambiarra".
Opção 5 - Utilizando a tag span
Essa opção combina um pouco da anterior com uma marcação a mais para não utilizar o text-ident. Neste "approach"é utilizado uma tag span dentro do título para esconder o texto e assim posicionar a imagem de fundo através do CSS.
Temos aqui um exemplo da marcação:
<h2><span>Titulo a ser substituido</span></h2> <p>lorem ipsum</p>
Então no CSS correspondente:
h2 {
background-image: url('titulo.gif');
display: block;
}
h2 span {
display: none;
}
Em termos de marcação HTML, utilizar uma tag span dentro de um título não "fere" os padrões, pois é um elemento inline dentro de elmento bloco. O display block é necessário se a tag for um link, pois a imagem é um elemento inline, neste caso do h2 é redundante por que ele já se comporta como elemento bloco. Não se deve deixar de lembrar também que é necessário dar dimensões ao elemento que será do tamanho da imagem. Isto foi omitido do exemplo por que depende do tamanho.
Exemplo da substituição por imagem, utilizado em um link
Conclusão
O objetivo deste post foi mostrar as diferentes possibilidades quando se deseja utilizar uma fonte que não seja de sistema. Minha intenção aqui não foi dizer qual é a melhor, mas sim expor todas elas. Normalmente vejo artigos que dizem sobre uma ou outra, mas que não abordam todas as possibilidades e geralmente possuem uma certa preferência que está de acordo com o método abordado. A escolha fica com vocês.
A maioria das suas visitas vêm de ferramentas de busca?
Postado em 16/04/2009 por Alexandre Magno
Ler comentários (2 comentarios)
Quando você analisa seu website, uma grande fatia da sua pizza vem de ferramentas de busca? Sua taxa de rejeição é alta? Esses dois fatores estão intimamente ligados, e seus resultados podem ter uma variedade de interpretações. Muitos usuários chegam ao seu site usando ferramentas de busca, acham seu objetivo e logo saem novamente. Algumas vezes outro assunto lhe chama atenção. A maioria deles estão lá somente para um objetivo: consegui a informação que querem, diretamente. Sendo assim, nem sempre taxa de rejeição alta pode ser considerada ruim. Ela em conjunto com grande parte vindo das ferramentas de busca mostram que o usuário consegue o que quer. Quanto mais rápido ele entrou em seu website e saiu, a taxa de rejeição aumentará proporcionalmente. No entanto tudo depende de muita análise, pois ele também pode ter saído por que não era aquele resultado que esperava.
Para se ter um melhor entendimento do quão rápido seu usuário entrou e saiu do seu site, se foi sucesso ou falho, outros números devem ser observados. Um deles é o Robot Replay, que infelizmente possuem uma ótima idéia, mas não funciona bem. Tive vários problemas com ele, mas é muito boa a idéia de ter um sistema web que grava o rastreamento de usuários. O problema é o impacto que isto pode causar na perfomance.
Na mesma medida, se você investe em qualquer tipo de campanha publicitária, deve ser analisado as visitas que são feitas diretamente(alguém simplesmente senta e digita o seu endereço para entrar no website). O resultado esperado é aumentar esta outra fatia de pizza muito importante. Ela muitas vezes mostra que seu site é conhecido e não está limitado a ser somente um resultado na busca realizada.
A web está cada vez mais dinâmica e os resultados de busca dominaram o mercado. Usuários que usam esses sistemas, por exemplo, para realizarem uma simples tarefa, também é utilizado como navegação. Quantas vezes você sabe como chegar em algum conteúdo específico, mas você utiliza o sistema de busca mesmo assim?
Quais são suas fontes de visitas e como vocês interpretam as ações de seus usuários?
Navegação em um site - Topo, esquerda ou direita?
Postado em 14/04/2009 por Alexandre Magno
Experiência do usuário, Usabilidade
Ler comentários (3 comentarios)
Muitas discussões foram levantadas para escolher a melhor forma de navegação em um website. Alguns tem preferência pelo topo (muitas vezes utilizando abas e menus drop-down), outros pela direita (que possibilita maior escabilidade) e ainda a navegação pela esquerda (que é a mais recente, tendo em vista o seu uso recorrente em Blogs). Existe a possibilidade também de usar uma combinação mista entre menu no topo com menus de contexto à direita ou esquerda. Existe uma minioria que falam sobre a disposição do menu na parte inferior, o "menu-bottom". Esta irei até desconsiderar no restante do post, pois hoje está sendo muito utilizada somente como reforço dos outros tipos de menu. Ou seja, menus na parte inferior estão sendo utilizados como navegação auxiliar.
A usabilidade em uma barra de navegação é extremamente importante para o sucesso e facilidade de uso de um serviço web. Não é coicidência que uma das primeiras decisões que precisam ser tomadas para iniciar qualquer esboço de um website é a disposição da navegação. Cada projeto é um caso e vários objetivos diferentes são alcançados com as decisões referentes a estas disposições. Muitos testes de usabilidade foram feitos para avaliar através do usuário a melhor forma de dispor a navegação.
Controle completo de formulários com o jQuery - Ajax Form e Validate
Postado em 04/04/2009 por Alexandre Magno
Melhores práticas, Plugins, jQuery avançado, Jquery
Ler comentários (13 comentarios)
Já expliquei em posts anteriores como usar o validade e como usar o Ajax Form. Agora irei mostrar como os dois em conjunto oferece uma solução completa para controle de formulários, validação cliente, remota e envio de dados por Ajax de uma forma simples, intuitiva, de fácil manutenção e para qualquer situação.
Será usado um exemplo prático com um formulário simples que possui os seguintes campos:
As validações que serão feitas serão as seguintes:
- Nome: é obrigatório e não poderá existir nomes duplicados (exemplo de validação remota)
- Idade: é necessário que seja número e não poderá ser maior que 18 (criação de um novo método de validação), já demonstrado anteriormente
- E-mail: precisa ser um e-mail válido
- País: precisa escolher ao menos uma opção
SWFUpload - Server-side
Postado em 25/03/2009 por Alexandre Magno
Ler comentários (4 comentarios)
Neste post irei demonstrar a regra de negócio por trás do SWFUpload, uma biblioteca javascript usada para controle de upload de arquivos no Browser utilizando o Flash. Ela controla o lado cliente enquanto o desenvolvedor a utiliza de uma forma extensível com a interface com o usuário. Em posts anteriores eu mostrei como esta interação pode ser feita com o jQuery, e muitas dúvidas surgiram de como receber os arquivos no lado servidor. Irei demonstrar utilizando o PHP com a framework CakePHP em como manipular os arquivos.
Foi utilizada o componente do cakePHP para este propósito.
Primeiramente, para acessar os arquivos no server-side utilizando PHP, temos basicamente o seguinte código:
$_FILE['Filedata'];
Sim, é a mesma forma como é recebido arquivos no server utilizando o input do tipo file. Esta biblioteca é totalmente não-obstrusiva. Você trata da mesma forma como trataria se o Javascript não estivesse habilitado. A diferença aqui é que ele faz a chamada para o script server-side a cada interação de upload, permitindo que seja feito múltiplos e com controles que não são possíveis com o upload padrão do formulário, como barra de progresso e tamanho do arquivo.
Onde colocar a tag script?
Postado em 14/03/2009 por Alexandre Magno
Ler comentários (Nenhum comentario)
Uma das regras de melhores práticas para otimizar a perfomance de um site, de acordo com o Yahoo é colocar a tag script logo antes da tag body do documento. Existe uma falha em fazer esta afirmação como regra.
Quando a página é carregada, o Browser ao carregar a tag script interrompe o processamento do restante do documento até que ele seja carregado completamente. Sendo assim, parece lógico você utilizar a tag script na parte inferior do documento ao invés do inseri-la no head (o mais utilizado). Desta forma o browser renderiza completamente, deixando para renderizar o script logo após a página ser carregada, dando uma reposta ao usuário mais rápida.
Situações como o Google Analitics, que orienta o usuário a inserir o script (captação para obter as estatísticas da página) na parte inferior, isto se aplica da forma correta, pois a página é carregada sem que o script do Google cause o decrescimento de perfomance no site. No entanto, no caso onde o script a ser carregado contém alguma interação com o usuário, este caso não deve ser aplicado pois se a página for renderizada ele está apto a interagir e clicar em links que possui eventos que não foram atribuidos a aquele elemento podem comprometer ao uso do site. Desta forma, o usuário pode interagir no momento inapropriado e não ter a experiência esperada do sistema.
A perfomance não deve afetar a integridade do sistema, então neste caso precisa ser balanceada. Mesmo sendo uma prática ditada pela Yahoo, ela possui esta grande falha e devemos saber dicernir melhores práticas para tomar decisões para melhorar perfomance.
Dependendo do tamanho dos scripts, a diferença de perfomance é considerável. Para tentar minimizar este problema, eu utilizo o carregamento de scripts sob demanda que desenvolvi para não carregar scripts desnecessários na página que muitas vezes nem use algum plugin do jQuery ou biblioteca exterior.
Campanha na Noruega para por fim ao IE6
Postado em 19/02/2009 por Alexandre Magno
Ler comentários (6 comentarios)
Uma nova manifestação contra o IE6 foi iniciada na Noruega. Ao contrário do movimento feito por vários desenvolvedores durante os últimos tempos, esta está sendo de cunho mais prático e foi adotada pelo Finn.no, um dos maiores sites comerciais da Noruega.
Os usuários do IE6 estão recebendo a seguinte notificação:
Você está usando uma versão antiga do Internet Explorer. Para ter o melhor deste website, você pode obter uma atualização grátis. Se você está usando o PC no trabalho, você deve contactar o administrador de TI
E não para por aí. Um dos maiores portais de notícias, o vg.no adotou a mesma iniciativa. Considerando que 20% da população Noruega visita este portal, o impacto é inevitável.
Isto são iniciativas que irão acelerar o declínio maior do Internet Explorer e possivelmente a sua extinção gradativa. As campanhas feitas por desenvolvedores não são suficientes na medida em que usuários comuns de grandes portais precisam perceber na prática esta necessidade.
Outros portais e grandes sites da Noruega tiveram a mesma iniciativa usando o mesmo padrão de mensagem.
Os usuários do Blog comentaram sobre a campanha do Imasters e é muito simples de ser aderida. Eu aderia a esta campanha e espero que todos vocês também. Breve poderemos chegar em iniciativas de grandes portais de conteúdo que possuem o público alvo essencial para extinguir o uso do IE6.
Reformulação no Blog
Postado em 15/01/2009 por Alexandre Magno
Ler comentários (1 comentário)
Ando um pouco sumido, mas ainda tenho frutos de tudo que publiquei. Sinto que agora mais do que nunca os artigos estão sendo referência para muitas pessoas. Estou fazendo uma reformulação geral para dar um passo a frente, mas não somente na programação, mas também no planejamento para se construir da melhor forma um projeto web que seja eficiente, modular e transparente para todos os envolvidos, seja usuário ou seja alguém que utiliza uma API para desenvolver soluções. Não só a nível de projeto publicarei, mas também as "features"que em conjunto forma todas as interações de qualquer sistema.
Não há como não misturar o que está acontecendo na sua vida profissional sobre os artigos que publica. Existe uma ética por trás disto tudo, mas que no fim defendo a idéia do software livre e a informação aberta. Um código exibido ao mundo é melhorado cada vez mais, sendo até estratégia de melhoria para o próprio criador. Com isto chegamos em ferramentas que estão se destacando no desenvolvimento web. O jQuery é a maior prova disto.
Passei por momentos onde lógicas complexas eram exigidas e o jQuery atendeu a todas. Desta forma foi possível vencer (sim é uma luta) as limitações dos Browsers e implementar as melhores soluções para o usuário. Por falar nisto, o usuário é a palavra chave de tudo que estou passando agora. Todos estamos desenvolvendo para este público alvo que se subdivide infinitamente. Desde quando desenvolvemos código a projetos de frameworks uma coisa é certa:
O nível e funcionalidades é proporcional a usabilidade de um sistema
Quanto mais detalhamos funcionalidades para se atingir a satisfação do usuário, maior o tempo do projeto e de custo. No entanto, o resultado final será um nível de satisfação infinitamente superior. A realidade é que o usuário está ficando cada vez mais exigente e serviços de excelência como a Google faz facilita o dia a dia. Um grande exemplo é o Google Maps, onde tive a oportunidade de conhecer e usá-la tanto o sistema mas também como desenvolvedor e oferecer soluções inovadoras usando as infinidades de possibilidades que ele oferece livremente. Sua documentação é impecável e atinge todos os níveis de usuário.
Quanto mais pessoas melhoram a forma que a internet é usada oferecendo as ferramentas para interagir com elas, seu projeto irá dar certo e as pessoas vão atingir o objetivo final: usar.
Lançamento do jQuery 1.3
Postado em 15/01/2009 por Alexandre Magno
Ler comentários (Nenhum comentario)
jQuery lança a versão 1.3 com uma série de melhorias significativas, principalmente quando se trata de perfomance. Assim que tiver mais informações publico aqui.
Maiores informações: jQuery 1.3
