Quais as vantagens de ter o Bootstrap no início do projeto ou até mesmo usar o bootstrap do twitter?
Parece algo tão óbvio: padronizar todos elementos de design se evolui de um ponto em que a etapa de definição de layout perca cada vez mais peso e num mundo ideal ela nem existiria, pois o desenvolvedor front-end já iria prever com o arquiteto a experiência de uso, pois a biblioteca é suficiente para suprir todas novas funcionalidade da aplicação. Usar o próprio bootstrap do twitter para prototipar é também algo extremamente útil, pois ele é bastante simples, limpo, agnóstico e com todos os recursos de CSS3.

Outra grande vantagens é para projetos novos que segue a mesma consistência visual.

O bootstrap é orgânico, de acordo com novos elementos ele vai crescendo e a tendência é que chegue em um limite. No entanto é necessário ter no mínimo:
•    Elementos do grid
•    Formulários
•    Tipografia
•    Cabeçalhos
•    Listas
•    Tabelas
•    Botões

Como vender a ideia?
Muitas vezes é difícil você conseguir negociar esta etapa. Ela simplesmente é muitas vezes ignorada ou até mesmo iniciada, mas descontinuada e logo depois abandonada. Neste último caso é um sintoma de outro ponto errado, provavelmente não há um padrão e sempre existe um atrito maior quando é necessário definir várias páginas e como um comportamento deve ser em uma determinada interação, como validações de formulário.

•  O plugin atual será depreciado. Não irei mais atualizá-lo devido a vários problemas que tive de torná-lo escalável com o modelo de plugins do jQuery.
• A interface foi melhoarada, e usando o jQuery UI, você pode escolher entre vários temas e estilos para seu plugin, bem como personalizar e gerar novos temas através do Theme Roller  .
• O plugin possui testes básicos com o Qunit, pois o pattern do jQuery ui possibilita melhor testá-lo unitariamente

Espero que gostem e qualquer feedback é bem vindo.

Breve, postarei mais exemplos de como usá-lo.

Você pode ver o projeto no github

Sendo assim, o plugin agora só tem um parâmetro que são as opções do plugin. Antes passando as opções do swfupload o desenvolvedor poderia quebrar o funcionamento atual sobrescrevendo eventos. Nesta versão o plugin possui todas as configurações e assim pode extender e customizar sem afetar as atuais funcionalidades.

Documentação

Os requisitos para o funcionamento do plugin estão listado abaixo:

• jQuery v1.3.2
• SWFUpload v2.1
• jQuery UI 1.7 (usando somente o efeito de highlight)

Suporte:

• IE 7+
• Chrome 1+
• Firefox 3+
• Safari 3+

* Não houve teste no IE6

Utilização

Primeiro, você deve incluir o plugin e suas dependências:
[sourcecode language="html"]

[/sourcecode]
Esta ordem é importante para que o plugin possa funcionar corretamente.

jqswfupload usa a biblioteca swfupload em conjunto com o jQuery. Então ele sobrescreve um simples input de arquivo com um sistema de upload múltiplos baseado em flash que possui todo o controle de progresso e tamanho do arquivo.

A marcação mínima para que o plugin possa funcionar está listada abaixo:
[sourcecode language="html"]

[/sourcecode]
Com esta marcação você pode invocar o plugin com as seguintes opções:
[sourcecode language="javascript"]

/*
* jQuery upload - main file
*/
$(document).ready(function(){
$("#upload-container").jqswfupload({
onUploadStart: function(file) {
$('#debug-bar').append('Upload Started: '+file.name);
},
onFileSuccess: function(file,data,response) {
$('#debug-bar').append('File success: '+ file.name + data);
},
onFileError: function(file,code,message){
$('#debug-bar').append('File Error: '+ file.name + message);
},
totalSize: '100 kb',
uploadUrl: upload_uri + 'upload.php',
// The post sent to server in the same request as the file object
post_params : {
'type' : 'swfupload',
'test' : 'val'
}
});
});

[/sourcecode]
O plugin usa um parâmetro, um objeto literal de opções
[sourcecode language="js"] $(‘container’).jqswfupload(options);

[/sourcecode]

Opções do Plugin

• uploadUrl
  a url que ira receber a lógica do upload
  tipo: string
  padrão: ‘../upload.php’
• flashUrl
  o caminho do arquivo swf da biblioteca swfupload
  tipo: string
  padrão: “libs/swfupload.swf”
• buttomPlaceholderId
  O id do elemento usado para identificar o container e onde tem inserido o upload do tipo file
  tipo: string
  padrão: ‘upload-placeholder’
• buttomImageUrl
  A url da imagem para adicionar o arquivo
  tipo: string
  padrão: ‘images/icon-add.gif’
• buttomText
  O texto do botão. ex.: “adicionar arquivos”
  tipo: string
  padrão:vazio
• buttomWidth
  A largura em pixels do botão
  tipo: number
  padrão: 172

• buttomHeight
  A altura em pixels do botão
  tipo: number
  padrão: 22
• fileTypes
  Os tipos de arquivos permitidos. ex.: “*.jpg,*.png”
  tipo: string
  padrão: “*.*”
• fileSizeLimit
  O limite de cada arquivo
  tipo: number
  padrão: 10000
• multiple
  Definir se o upload será múltiplo
  tipo: boolean
  padrão: true
• cursorType
  Definir tipo de cursor
  tipo: string
  padrão: ‘hand’
• dialogDescription
  O cabeçalho da descrição do diálogo de upload do browser
  tipo: string
  padrão: “Web Image Files”
• columns
  Os rótulos das colunas na interface de upload
  tipo: object
  padrão:
  columns: {
  file : ‘File’,
  size : ‘Size’,
  action : ‘Action’
  }
• messages
  As mensagens usadas para darem as diferentes notificações
  tipo: object
  padrão:
  messages : {
  file_size_limit : ‘You reach the total size’,
  file_already_exist : ‘Some(s) of the file already exist, the other(s) was included’,
  browser_upload : ‘Are you having problem with this upload? Try the common upload instead’,
  start: ‘Start upload’,
  all_completed: ‘All uploads are completed’
  }
• totalSize
  O tamanho total dos arquivos permitidos. Pode passar em bytes, kb ou MB
  tipo: string
  padrão: ’5 MB’
• messageDelay
  O tempo que as mensagens de notifiação permanecem na tela
  tipo: number
  padrão: 3000
• post_params
  Dados adicionais enviados via post para cada tipo de arquivo no formato chave : valor
  tipo: object
  padrão: empty object

Callbacks

onFileQueue(file)
onDialogClose(files_selected,files_queued,total_queued)
onSwfuploadLoaded()
onUploadStart(file)
onUploadProgress(file,completed,total)
onFileComplete(file)
onFileError(file,error,message)
onFileSuccess(file,data,response)

[sourcecode language="javascript"]

//formato dos parametros adicionais

post_params : {

“post_param_name_1″ : “post_param_value_1″,

“post_param_name_2″ : “post_param_value_2″,

“post_param_name_n” : “post_param_value_n”

},

[/sourcecode]

Para uma completa referência das opções do swfupload, veja a documentação do swfupload

Dúvidas frequentes

Aqui está uma lista das dúvidas frequentes que podem ocorrer ao utilizar o jqswfupload:

Qual a vantagem deste plugin em relação a utilizar o swfupload sozinho?

SWFUpload é uma ótima biblioteca utilizada amplamente em grandes projetos para realizar uploads múltiplos. Ela torna fácil a integração do flash com a interface web que não seja puramente nesta tecnologia. Entretanto, o swfupload tem muitos eventos, callbacks e opções que permite a flexibilidade para o desenvolvedor criar a experiência completa de upload utilizando javascript para criar todo o dom necessário para fazer isto acontecer. Este plugin é baseado na experiência do usuário utilizada no upload de fotos do Flickr. Toda a interface pode ser customizada por CSS. Com algumas vantagens, o jqswfupload estende as funcionalidades do swfupload, como progresso geral de arquivo e limitação de tamanho máximo da fila, não simplesmente limitar o tamanho de um único arquivo. O plugin foi construído para tornar este tipo de upload da “maneira jQuery de ser” que com uma linha você pode ter tudo funcionando e você tem o objeto de opções para ter o poder de mudar de acordo com sua necessidade.

O upload retorna um erro 404, o que pode ser isto?

Provavelmente a opção upload_url do swfupload não está correta. Não se esqueça de tornar o link absoluto ou relativo ao caminho do plugin.

Eu segui todos os passo na documentação, mas aina aparece um input de arquivos normal, o que pode ter acontecido?

Provavelmente você não colocou corretamento o arquivo swf ou não modificou a opção flash_url. Não se esqueça que esta opção é relativa ao template.

Eu posso customizar todas as opções do swfupload?

Sim, usando o plugin você consegue usar os eventos do plugin que são análogos a vários eventos do swfupload, a diferença é que eles são acionados depois da interface gerada, sendo assim você pode personalizar e executar as ações que desejar

Eu fiz download do plugin e o arquivo upload.php não tem nenhuma lógica de realizar upload, o que aconteceu?

O script upload.php simplesmente prova que a cada upload realizado o script é chamado. O script pode ser escrito em diferentes linguagens de servidor e é assumido que quem esteja utilizando este plugin tem algum conhecimento prévio com envio de upload e o está utilizando para melhorar a experiência do usuário que é prejudicada com o upload de arquivos ormal. Se tiver algum exemplo de implementação do script de upload, por favor, entre em contato

Todo o codebase será migrado para o Git até 15 de Agosto. Sendo assim, o projeto não estará mais hosteado no GoogleCode, mas sim no Github:
http://github.com/jquery
Então se quiserem baixar o último código fonte do projeto a partir de 15 de Agosto terão que usar o clone do Git, ou visualizar o código no Github.

Por que a mudança?
Esta mudança está seguindo uma tendência normal de como o git vem crescendo para grandes projetos, por suportar múltiplos repositórios, controle de versao local, commits locais, merge automático (em alguns casos) e ser mais rápido que o SVN (e menos doloroso). Em relação aos plugins, o core do jQuery não irá mais se misturar com o restante do repositório e cada um pode gerenciar seus plugins da forma que lhe convir.
Para saber mais sobre o Git:
http://vainalousachefe.wordpress.com/2008/02/21/introducao-ao-controle-de-versao-local-com-git/

Houve também muito cuidado para preservar uma ótima experiência do usuário. A interface foi baseada no upload de fotos do Flickr.

O plugin terá novas versões em breve com melhorias contínuas e até a possibilidade de criar extensões para fazer upload de imagens com opção de edição como redimensionar e cortar.

Documentação

Os requisitos para o funcionamento do plugin estão listado abaixo:

• jQuery v1.3.2
• SWFUpload v2.1
• jQuery UI 1.7 (usando somente o efeito de highlight)

Suporte:

• IE 7+
• Chrome 1+
• Firefox 3+
• Safari 3+

* Não houve teste no IE6

Utilização

Primeiro, você deve incluir o plugin e suas dependências:
[sourcecode language="html"] 

[/sourcecode]
Esta ordem é importante para que o plugin possa funcionar corretamente.

jqswfupload usa a biblioteca swfupload em conjunto com o jQuery. Então ele sobrescreve um simples input de arquivo com um sistema de upload múltiplos baseado em flash que possui todo o controle de progresso e tamanho do arquivo.

A marcação mínima para que o plugin possa funcionar está listada abaixo:
[sourcecode language="html"] 

[/sourcecode]
Com esta marcação você pode invocar o plugin com as seguintes opções:
[sourcecode language="javascript"]$(“#upload-container”).jqswfupload({
onFileSuccess: function(file,data,response) {

//execute when happen the upload file success

},

onFileError: function(file,code,message){

//execute when happen the upload file error

}

},

{

upload_url:  ‘./upload.php’

});

[/sourcecode]
O plugin aceita dois objetos como parâmetros, o primeiro são as opções do plugin como um objeto literal e o segundo um objeto de settings do swfupload.
[sourcecode language="js"] $(‘container’).jqswfupload(Object plugin_options, Object swfupload_options);

[/sourcecode]

Opções do Plugin

• container (padrão: #upload-container) : O seletor de contexto de onde o plugin age. Pode ser um id ou classe do formulário onde o input do tipo file está localizado.
• total_size (padrão: 5 MB) : O tamanho máximo da fila total.
• message_delay (padrão: 3000) : O tempo em milisegundos que as mensagens de aviso ou sucesso permanece na interface.
• columns (Padrão: Object) : O objeto com o texto padrão das colunas. As chaves do objeto são file, size and action que referenciam ao arquivo, tamanho e ação (remover arquivo). Quando uma das opções é passada, é obrigatório que você especifique as demais.
• messages (padrão: Object) : O objeto com mensagens padrões. As chaves atualmente são file_size_limit, file_already_exist, browse_upload e start. Quando uma das opções é passada, é obrigatório que você especifique as demais.
• onFileSucces(file,data,response) : O callback invocado a cada sucesso do arquivo
  • file: Um objeto que carrega informações do arquivo, como nome, tamanho e um identificador único
  • data: Os dados enviados ao servidor
  • response: A resposta vinda do servidor. Esta é a resposta dada pelo script de upload e você pode retornar json, xml ou pedaços de html para serem tratados.
• onFileError(file,error,message)
  • file: Um objeto que carrega informações do arquivo, como nome, tamanho e um identificador único
  • error: O código de erro do arquivo
  • message: A mensagem de erro

Opções do swfupload

• upload_url (padrão: ../upload.php ): A url relativa ao plugin
• flash_url (padrão: libs/swfupload.swf) : O caminho do arquivo swfupload.swf relativa ao local onde o script é chamado
• button_placeholder_id (padrão: upload-placeholder): O id do elemento que será substituído pelo upload em flasho, geralmente o input id ou uma div pai do input do tipo file
• post_params (Objeto) : Dados adicionais para serem enviados junto com o post do arquivo. Neste post você pode enviar dados de formulário, identificadores de sessão etc. Ele segue o seguinte formato:

[sourcecode language="javascript"]

post_params : {

“post_param_name_1″ : “post_param_value_1″,

“post_param_name_2″ : “post_param_value_2″,

“post_param_name_n” : “post_param_value_n”

},

[/sourcecode]

Para uma completa referência das opções do swfupload, veja a documentação do swfupload

Dúvidas frequentes

Aqui está uma lista das dúvidas frequentes que podem ocorrer ao utilizar o jqswfupload:

Qual a vantagem deste plugin em relação a utilizar o swfupload sozinho?

SWFUpload é uma ótima biblioteca utilizada amplamente em grandes projetos para realizar uploads múltiplos. Ela torna fácil a integração do flash com a interface web que não seja puramente nesta tecnologia. Entretanto, o swfupload tem muitos eventos, callbacks e opções que permite a flexibilidade para o desenvolvedor criar a experiência completa de upload utilizando javascript para criar todo o dom necessário para fazer isto acontecer. Este plugin é baseado na experiência do usuário utilizada no upload de fotos do Flickr. Toda a interface pode ser customizada por CSS. Com algumas vantagens, o jqswfupload estende as funcionalidades do swfupload, como progresso geral de arquivo e limitação de tamanho máximo da fila, não simplesmente limitar o tamanho de um único arquivo. O plugin foi construído para tornar este tipo de upload da “maneira jQuery de ser” que com uma linha você pode ter tudo funcionando e você tem o objeto de opções para ter o poder de mudar de acordo com sua necessidade.

O upload retorna um erro 404, o que pode ser isto?

Provavelmente a opção upload_url do swfupload não está correta. Não se esqueça de tornar o link absoluto ou relativo ao caminho do plugin.

Eu segui todos os passo na documentação, mas aina aparece um input de arquivos normal, o que pode ter acontecido?

Provavelmente você não colocou corretamento o arquivo swf ou não modificou a opção flash_url. Não se esqueça que esta opção é relativa ao template.

Eu posso customizar todas as opções do swfupload?

Sim, mas não é recomendado para esta primeira versão modificar os eventos, por que eles irão sobrescrever os eventos do plugin. Estou realizando o trabalho de estender todos os eventos do swfupload para o plugin para estender as opções existentes sem sobrescrever os eventos atuais. Por enquanto você pode usar os callbacks onFileSuccess e onFileError.

Eu fiz download do plugin e o arquivo upload.php não tem nenhuma lógica de realizar upload, o que aconteceu?

O script upload.php simplesmente prova que a cada upload realizado o script é chamado. O script pode ser escrito em diferentes linguagens de servidor e é assumido que quem esteja utilizando este plugin tem algum conhecimento prévio com envio de upload e o está utilizando para melhorar a experiência do usuário que é prejudicada com o upload de arquivos ormal. Se tiver algum exemplo de implementação do script de upload, por favor, entre em contato

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:

1
2
3
4
5
6
7
8

<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>
 
<form action="/" method="post">
<label for="calendario">Data:</label>
<input id="calendario" type="text" name="calendario" />
</form>

<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>

<form action="/" method="post">
<label for="calendario">Data:</label>
<input id="calendario" type="text" name="calendario" />
</form>

O arquivo calendário.js contém o seguinte conteúdo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$(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'
 
});
});

$(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.

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

[sourcecode language="html"]

Titulo a ser substituido

lorem ipsum

[/sourcecode]

Então no CSS correspondente:

[sourcecode language="css"]

h2 {

background-image: url(‘titulo.gif’);

text-ident: -999;

overflow: hidden;

}

[/sourcecode]

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:

[sourcecode language="html"]

Titulo a ser substituido

lorem ipsum

[/sourcecode]

Então no CSS correspondente:

[sourcecode language="css"]

h2 {

background-image: url(‘titulo.gif’);

display: block;
}

h2 span {

display: none;

}

[/sourcecode]

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.

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?

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.

O comportamento do usuário, assim como suas interações com o website são pesquisadas e muito utilizados como base para  uma decisão como esta. Uma opinião pessoal, de cliente e até mesmo de especialista podem entrar em contradição com o comportamento dinâmico de uma população em como eles devem agir. Um bom exemplo a ser dado são e-commerces, em que usuários tornaram-se grandes consumidores. Neste contexto, uma maior importância foi estabelecida a todas as suas ações, que foram pesquisadas e avaliadas de forma que se chegue em um sistema mais eficiente. Hoje lojas virtuais consagradas possuiem padrões de navegação muito confortáveis e com uso bastante eficiente.

Não se precipite em dizer que a melhor escolha é a esquerda como muitos o fazem. Como Nielsen já esperava, várias implementações ruins se tornam padrões na web. Não é errado fugir de um padrão, pois criar novos padrões é criar novas perspectivas para o usuário interagir com o sistema, que muitas vezes não é tão familiar como parece.

Navegação tradicional – Menu a esquerda

Muitos guias de design surgiram na última década. Grande parte deles estavam com uma certa aceitação mútua de que a melhor utilização dos menus seriam na esquerda. Entre eles, Jacob Nielsen, um dos grandes nomes quando o assunto é usabilidade reforçaram esta idéia. Guias de Design utilizados pela IBM também aderiram o uso do padrão de menus conhecidos como “L invertido”. Pesquisas feitas na IBM constataram que esta forma de navegação é a mais confortável para o usuário.

Foi realizada uma pesquisa com a finalidade de obter modelos mentais de como os elementos devem ser dispostos em um site (sistema de busca, login, menus de navegação). Foram gravados o tempo gasto dos usuários para se completar uma tarefa utilizando os diferentes tipos de menu. De acordo com os autores deste estudo mostram que o lugar ideal para a navegação é na esquerda devido ao processamento de informação no cérebro humano. A área esquerda é melhor usada para completar tarefas enquanto o lado direito é melhor para discursos e leitura. O estudo ainda mostrou que usuários mais avançados muitas vezes produzem melhores experiências navegando com menus ao topo em combinação com menus de contexto a esquerda.

O fato é que o menu na esquerda tem muitas vantagens. Uma delas é a escabilidade, pois ela se adapta muito bem a grandes portais ou websites que crescem exponencialmente. Mas nem sempre ela é a melhor opção.

Formas alternativas

As formas alternativas ganharam muito destaque depois que pesquisas de usabilidade começaram a serem amplamente utilizadas. Estudos recentes mostram que a disposição na direita é bastante eficiente, pois o usuário está mais próximo da barra de rolagem. Com isto o tempo final para navegar em um website é bastante reduzido, aumentando a eficiência do usuário seguir seus objetivos. O problema que apesar de estar próximo da barra lateral, ele está mais distante do botão de voltar do browser, o que diminiu a eficiência nesses casos.

Estudo de caso – Redesign Audi.com

Foi realizado testes de perfomance para saber a eficiência da disposição de menus à esquerda em relação a menus à direita. Este teste foi aplicado ao redesign do site da Audi.com e Audi.de. Os testes foram realizados em Hamburgo, Alemanha.

Este teste foi realizado com 64 participante (44 homens e 20 mulheres). Todos participantes são público alvo da empresa.

Foram utilizados dois protótipos clicáveis para com os dois arranjos de menu: esquerda e direita. Todos os outros elementos foram mantidos constantes para não afetar a eficiência do teste.

Os participantes foram divididos e orientados a completarem as seguintes tarefas:

• Enviar e-mail para a compania sobre o serviço
• Encontrar um representante da Audi em Hamburgo
• Encontra informações sobre um modelo específico de carro
• Configurar um carro online

Todas as tarefas foram cronometradas. O resultado obtido mostrou que não há diferença considerável de perfomance em utilizar navegação à direita. No entanto, com essa nova perspectiva de navegação à direita, muitas vantagens foram descobertas:

• Como previsto por Jacob Nielsen, uma navegação à direita foca o usuário no conteúdo. Isto justifica o motivo pelo qual grande parte dos Blogs usa este tipo de navegação
• Usuários destros, que é grande maioria, se sentem mais confortáveis com navegação à direita. Usuários destros tendem a direcionar seu movimento à direita, além de terem uma maior proximidade da barra de rolagem.

Conclusão

A resposta final para esta pergunta é meio óbvia para alguns e irritam muitos outros: não existe melhor local para disposição de menus. Depende do projeto, do foco e de toda arquitetura de informação do sistema em questão. Para tomar esta decisão, além de pesquisas com usuários, as considerações aqui passadas pode servir como o começo de uma discussão.

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

O código da marcação HTML é bem direto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<form name="validate" id="validate" action="enviar_dados.php" method="post">
 
<label for="nome">Nome:</label>
<input type="text" name="nome" />
 
<label for="idade">Idade:</label>
<input type="text" name="idade" />
 
<label for="email">E-mail:</label>
<input type="text" name="email" />
 
<label for="pais">Pa&iacute;s:</label>
<select type="text" name="pais">
<option value="">Selecione</option>
<option value="brasil">Brasil</option>
<option value="canada">Inglaterra</option>
</select>
 
<input type="submit" value="Validar" />
 
</form>

<form name="validate" id="validate" action="enviar_dados.php" method="post">

<label for="nome">Nome:</label>
<input type="text" name="nome" />

<label for="idade">Idade:</label>
<input type="text" name="idade" />

<label for="email">E-mail:</label>
<input type="text" name="email" />

<label for="pais">Pa&iacute;s:</label>
<select type="text" name="pais">
<option value="">Selecione</option>
<option value="brasil">Brasil</option>
<option value="canada">Inglaterra</option>
</select>

<input type="submit" value="Validar" />

</form>

Depois de ter inserido o jQuery, Validate e Form Plugin no cabeçalho, podemos usá-lo para validar o formulário de acordo com as regras estabelecidas. Irei demonstrar o código e depois explicar cada item:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

$(function(){
 
$("#validate").validate({
 
submitHandler: function(form) {
$(form).ajaxSubmit({
dataType: 'html',
 
success: response
});
},
rules: {
nome: {
required: true,
remote: 'remote.php'
},
idade: {
required: true,
minAge: 18
},
email: {
required: true,
email: true
},
pais: 'required'
},
messages: {
nome: {
required: 'Você não preencheu seu nome',
remote: 'Este nome ja existe'
},
idade: {
required: 'Você não preencheu sua idade'
},
email: {
required: 'Você precisa preencher um e-mail',
email: 'Endereço de e-mail não válido'
},
pais: 'Você precisa escolher um país'
}
 
});
 
});

$(function(){

$("#validate").validate({

submitHandler: function(form) {
$(form).ajaxSubmit({
dataType: 'html',

success: response
});
},
rules: {
nome: {
required: true,
remote: 'remote.php'
},
idade: {
required: true,
minAge: 18
},
email: {
required: true,
email: true
},
pais: 'required'
},
messages: {
nome: {
required: 'Você não preencheu seu nome',
remote: 'Este nome ja existe'
},
idade: {
required: 'Você não preencheu sua idade'
},
email: {
required: 'Você precisa preencher um e-mail',
email: 'Endereço de e-mail não válido'
},
pais: 'Você precisa escolher um país'
}

});

});

A diferença deste código em relação ao post anterior sobre o validate é o fato de agora existir uma validação remota. Observe a nova regra ‘remote’, em que podemos passar uma  url que será passado o valor daquele campo (por padrão como get), então ele irá esperar uma resposta no formato JSON com simplesmente um valor true ou false. Neste caso, como no código abaixo ele verifica se já existe um nome ‘alexandremagno’:

1
2
3
4
5
6
7
8
9
10

<?php
 
$nome = $_GET['nome'];
if($nome == 'alexandremagno') {
echo 'false';
} else {
echo 'true';
}
 
?>

<?php

$nome = $_GET['nome'];
if($nome == 'alexandremagno') {
echo 'false';
} else {
echo 'true';
}

?>

Vale lembrar que este não é um código utilizado na prática, pois é simplesmente como demonstração. No server-side, devemos verificar nomes duplicados de acordo com o banco de dados, então provavelmente seria um select verificando se já existe este nome no banco de dados. O exemplo simples ilustra a situação. Com o este método, poderemos unificar no validate para toda resposta sobre validação, mesmo que seja remota. Não haverá mais desta forma diferenciação entre validação cliente/servidor. Apesar disto, a verificação no  back-end deve ser feita (para usuários que não tenha javascript habilitado ou que desabilitem o javascript).

O método submitHandler do Validate

Este método é onde os dois plugins se encontram. Com este método podemos controlar o que irá acontecer no envio do formulário. Quando não é utilizada, ela irá enviar o formulário normalmente. Após utilizá-la, podemos passar o formulário como parâmetro e usá-lo para por exemplo, impedir que o formulário seja enviado e assim podermos utilizar um envio por ajax ou qualquer lógica dependendo da situação. Neste caso nós o utilizamos para chamar o Ajax Form:

1
2
3
4
5
6

submitHandler: function(form) {
$(form).ajaxSubmit({
type: 'post',
success: response
});
},

submitHandler: function(form) {
$(form).ajaxSubmit({
type: 'post',
success: response
});
},

No sucesso, passamos uma função chamada response que irá enviar os dados e retornar a mensagem de sucesso que será inserida no DOM como se segue:

function response(data) {
$("#validate").resetForm();
$('#mensagem').remove();

var mensagem;

if(data) {

mensagem ='Dados validados com sucesso';

} else {

mensagem = 'Não foi possível validar os dados';

}

$('<div id="mensagem">'+mensagem+'</div>')
.hide()
.insertAfter('h1')
.fadeIn('slow');
}

A função response aceita o parâmetro data que é o retorno da requisição feita por ajax. Vale lembrar que este uso pode ser totalmente não-obstrusivo, pois várias frameworks já possuem métodos em suas classes para identificar a natureza da requisição e retornar o tipo de dado adequado. Neste caso o retorno é uma parte de HTML que pode ser usado para ser inserido no DOM.

Primeiramente usamos um método do Form Plugin que limpa todos os dados do formulário, depois remove qualquer div com o id mensagem para evitar que seja inserida novamente. Logo depois os dados vindos da requisição são inseridos com um efeito fade logo após o título. Tive que utilizar o método hide do jQuery antes, pois o efeito fade pode é percebido em um elemento que esteja inicialmente escondido.

Desta forma, o controle de formulário fica totalmente na responsabilidade desses dois plugins integrados. Para formulários maiores e lógicas mais complexa podemos seguir o mesmo raciocínio sem maiores problemas.