27/12/2008

Websites para mobile não são miniaturas dos sites convencionais - parte II

Como visto no artigo anterior, páginas desenvolvidas para dispositivos móveis têm características singulares e diversos quesitos a serem seguidos no momento de confeccioná-las. Um destes critérios é o DOCTYPE adequado, que permite tanto a correta renderização das páginas quanto a validação e mensuração das mesmas.

O Doctype correto para WAP

Os navegadores de dispositivos móveis são mais exigentes. As páginas devem ser construídas como XHTML strict, ou seja, não há tolerâncias para tags que não pertençam mais ao XHTML. Fazemos esta indicação através de um Doctype específico para WAP que é utilizado, inclusive, pelas ferramentas de depuração para avaliar se o site contém erros de marcação e semântica. O Doctype a ser utilizado é o seguinte:

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml">

Sem esta declaração no topo do documento, alguns navegadores nem ao menos abrem a página.

Testando e validando sua aplicação

Uma questão importante é saber de fato como o seu website irá aparecer nos dispositivos móveis. Quando eu acreditava que apenas um CSS era suficiente para fazer de um site mobile-friendly, testava apenas mudando o media-type e reduzindo o tamanho da janela do navegador. Ledo engano.

A renderização irá depender dos dispositivo, do navegadores e da resolução utilizados. Além disso, é preciso avaliar questões como o custo e tempo do carregamento. Mas como?

O site ready.mobi, que me forneceu embasamento para o artigo anterior, possui uma ferramenta de mobile-checker. Ela avalia o custo, o tamanho da página, fornece um ranking (de 0 a 5) e aponta acertos e erros baseados em determinadas premissas como a semântica do código, uso de folhas de estilos, configurações de performance, etc. Além disso, ele possui um simulador onde é possível testar sua aplicação em aproximadamente 5 aparelhos distintos.

Não podemos esquecer também o OperaMini, que ganhou um artigo há mais de dois anos aqui no blog. O simulador do OperaMini - navegador presente em diversos aparelhos - permite testar sua aplicação como se estivesse realmente utilizando a interface de um celular.

Adobe Device Central

Mas o destaque maior dentre as ferramentas que já utilizei vai para o Adobe Device Central, software presente a partir do Creative Suite 3, que possui integração com o Dreamweaver e permite testar em centenas de aparelhos de diversos fabricantes com resoluções diferentes, com direito até à skin do celular que está sendo utilizado. Com esta ferramenta, é possível ver claramente as discrepâncias na renderização das páginas web de acordo com o aparelho.

Outros simuladores

Para quem busca softwares que simulam outras plataformas de mobile, sugiro os sites da Nokia, BlackBerry e Windows Mobile, que possuem até mesmo alguns SDKs para desenvolvimento e outros tipos de aplicativos. Para o iPhone e iPod Touch, a renderização das páginas em mobile é normal utilizando o Safari, pois ele é capaz de dar zoom nos elementos a serem interagidos pelos usuário. Entretanto, você pode fazer o download do SDK para iPhone e desenvolver executáveis para o aparelho, mas precisará ter um Mac.

Validando o código segundo o W3C

Há agum tempo atrás, o W3C possuia apenas as diretrizes para mobile, mas não havia desenvolvido um validador específico para este fim.

Mas recentemente foi inaugurado o W3C Mobile Checker, que possui a mesma função do validador padrão de XHTML. Diferentemente do ready.mobi, que segue as diretrizes do W3C para realizar a validação, o Mobile Checker "oficial" é muito mais rigoroso, porém, completo.

Bom, pessoal, ficam aí as dicas das principais práticas para quem deseja se aventurar neste pequeno mundo móvel, que ainda tem muito a oferecer e modificou a maneira de se pensar sobre web.

Até a próxima e Feliz Ano Novo!

:)

Referências

Ready.mobi

CYBIS, W, et.al. Ergonomia e Usabilidade: Conhecimento, Métodos e Aplicações. São Paulo: Novatec Editora, 2007.

Linha de Código - Introdução à tecnologia WAP

3 pessoas comentaram o post até agora.

8/12/2008

Websites para mobile não são miniaturas dos sites convencionais - parte I

Depois de (mais uma) temporada fora da rede graças ao famigerado final de semestre da faculdade, estou de volta à blogosfera e pretendo tirar do papel - literalmente - todos os meus artigos acumulados até o momento.

Bem, antes de começar o assunto de hoje, ainda não foi neste ano que virei Peixe Grande. A concorrência era forte, competente e numerosa, rs. Mas apenas competir sempre vale a pena, parabéns aos vencedores e obrigada a todos que votaram em mim.

Agora sim, falemos de mobile. Depois de ter participado, no início do ano, do desenvolvimento da versão mobile para o software eDirectory, pude aprender muito sobre aquele pequeno mundo de 180x200 pixels e muitos dos conhecimentos que eu tinha sobre o assunto foram completamente renovados, pois descobri muitas particularidades interessantes do ambiente móvel. Portanto, gostaria de compartilhar o meu aprendizado na parte do design de interface. As dicas da seção 2 do artigo foram retiradas do site ready.mobi, ferramenta muito útil avaliação e que será explorada na seção 3, presente no próximo artigo.

1º) Mitos/dogmas x Verdades

Quando se fala em desenvolviemento para mobile, as pessoas tendem a reagir de dois modos extremos: acreditam que é complexo demais, pois é completamente diferente da web "convencional"; ou acreditam ser muito simples, por ser uma versão minimalista do site utilizando apenas uma folha de estilos para este tipo de dispositivo. Eu me enquadrava no segundo perfil.

A verdade é que as diretrizes para desenvolvimento mobile compreendem um conjunto amplo de práticas que não se encontram em nenhum dos extremos, mas sim no meio termo.

O objetivo de um site para dispositivos móveis é oferecer informações diretas e sucintas e/ou prover tarefas específicas, geralmente as mais usuais do site/aplicação convencional. Unindo à isso as limitações físicas do aparelho (telas reduzidas, número de cores, utilização totalmente dependente do teclado) e o contexto do usuário (uso em movimento, imediatismo na entrega das informações e acesso fácil), temos a prova de que a interface de websites para mobile não deve ser uma reprodução miniaturizada do site original, como afirma Cybis et.al. (2007), apenas reduzindo cores e tamanhos de fontes, pois os modelos de interação são completamente diferentes. Como veremos abaixo, nem mesmo o HTML deve ser o mesmo. Portanto mediatype="handheld" não é suficiente para fazer um site acessível via dispositivos móveis.

2º) As regras de ouro

CSS e Apresentação

Utilize porcentagens e medidas relativas como em, ex, bolder, larger e thick.

A utilização de tabelas para o layout é considerada uma prática ruim, principalmente para dispositivos móveis. O layout das páginas é efetuado de modo mais eficiente utilizando CSS e o layout resultante é mais fácil de linearizar e renderizar em um contexto reduzido, como as telas dos dispositivos móveis. Além disso, o uso de tabelas quebra a distinção entre a estrutura sendo representada separadamente do layout.

Não utilize marcação inline como, por exemplo <b>texto</b>, para modificar a apresentação de sua página. O uso de CSS auxilia na consistência de estilo e a centralização ajuda a reduzir o peso da página.

Minimização de custo

O tamanho das páginas (incluindo imagens e folhas de estilo), em kilobytes, deve ser pequeno uma vez que páginas páginas "grandes" demoram para carregar e, em algumas operadoras, aumentam os custos do acesso.

Não utilize marcações para redirecionar páginas, pois isto incorre no custo de carregamento e processamento da página. Ao invés disso, configure o servidor para realizar redirecionamentos utilizando os códigos HTTP 3xx.

Observe que os redirecionamentos devem ser evitados para todos os custos pois cada um aumenta tanto tempo quando custo de visualização da página final.

O uso de informações em cache pode reduzir a necessidade de carregar novamente recursos como imagens e folhas de estilos, reduzindo também tempo e custo de download. Cache é particularmente importante para dispositivos móveis devido à alta latência tipicamente apresentada nas redes móveis.

Usabilidade e Acessibilidade

Uma boa prática a ser utilizada, exceto para pequenos documentos, é indicar a estrutura do mesmo através de tags de título e subtítulos. Utilizar marcação estrutural, no lugar de efeitos de formatação permite uma adaptação fácil do conteúdo onde ele precisa ser dividido em muitas páginas, bem como potenciamente facilitar o acesso a seções do documento nas quais o usuário está interessado. Nos lugares onde as tags de cabeçalho (título e subtítulos) são utilizadas, elas devem ser aplicadas de acordo com a especificação, ou seja, aninhadas corretamente de acordo com o nível de cada uma.

A menos que você saiba que o dispositivo é capaz de submeter um formulário sem um botão de submit (ex.: utilizando javascript), deve ser garantido que cada formulário presente no site tenha um botão de submit. Caso contrário, os usuários poderão não utilizar seu site corretamente.

Valores padrões pré-selecionados para campos de formulários devem ser providos sempre que possível, pois isto reduz a quantidade de entrada de dados que o usuário deve fazer. Dadas as limitações dos dispositivos móveis, a interface interface deve minimizar ao máximo as entradas de dados do usuário. Quando possível, utilize listas de seleção, radio buttons e outros controles que não requerem digitação.

O título da página deve ser curto e descritivo para permitir uma fácil identificação, mas tenha em mente que ele pode ser truncado quando visualizado nos dispositivos móveis. Muitos dispositivos usam o título da página como um rótulo padrão para os bookmarks, então o título deve ajudar a identificar o conteúdo.

Não tente abrir janelas pop-up, pois muitos dispositivos móveis não têm suporte a este recurso. Mesmo quando eles são suportados, mudar a janela atual sem informar o usuário pode causar confusão.

Muitos dispositivos móveis não suportam elementos embutidos (ex.: flash) ou scripts e, em muitos casos, o usuário não tem condições de baixar um plug-in para dar suporte a estes recursos. Por isso, o conteúdo deve ser projetado com isto em mente. Mesmo quando o dispositivo suporta scripts, não os utiliza a menos que não haja outra forma de atingir seus objetivos. Scripts aumentam o consumo de energia e diminuem a vida útil da bateria.

Renderização

Evite medidas absolutas e em pixels, permitindo que os navegadores ajustem o conteúdo à tela. Uma exceção à regra é quando uma imagem foi dimensionada especificamente para um formato de tela. Neste caso, as referência da imagem na marcação podem especificar as dimensões exatas da imagem em pixels para ajudar o navegador a continuar o carregamento da página e evitar o recarregamento depois da página ter sido exibida por completo. Os dispositivos podem perceber melhor as intenções do desenvolvedor se as margens, bordas e espaçamentos forem especificados em pixels.

A página deve ser organizada de modo que o conteúdo possa ser lido sem as folhas de estilos.

No próximo artigo...

Mais diretrizes de usabilidade para mobile, dicas de ferramentas e qual o DOCTYPE correto em documentos XHTML exibidos em dispositivos móveis.

Referências

Ready.mobi

CYBIS, W, et.al. Ergonomia e Usabilidade: Conhecimento, Métodos e Aplicações. São Paulo: Novatec Editora, 2007.

3 pessoas comentaram o post até agora.

6/10/2008

Quero ser Peixe Grande!

Começou mais uma edição do concurso Peixe Grande, maior premiação de Web Design no Brasil promovida pela Arteccom e, este ano, volto a concorrer ao prêmio nas categorias Freelancer e na recém-criada Blog.

Gostaria de pedir a todos que contribuissem com o seu voto (parece até discurso de político, rs):

Vote www.talitapagani.com na categoria Freelancer

Vote blog.talitapagani.com na categoria Blog

Obrigada ;)

1 pessoa comentou o post até agora.

17/9/2008

Bug do Dreamweaver impede execução do programa

Esta semana experimentei um erro curioso (para não dizer catastrófico) no Dreamweaver CS3 e não tinha como não compartilhá-lo com todo mundo, pois foi simplesmente hilário. Sexta-feira (12/09), estava utilizando o DW normalmente e, quando alterei o valor de um padding para 0, o programa encerrou de modo abrupto. Tentei abrí-lo novamente n vezes, mas ele fechava ainda na Splash Screen, exatamente no momento do Loading Cache. Perguntando a alguns colegas e ao "Oráculo", acreditando que pudesse ser realmente algum problema de cache. Tentei excluir arquivos do site cache, modificar outras configurações diretamente na pasta do aplicativo, mas o problema persistia.

Relutando em utilizar outro editor, baixei uma versão portable do DW. Pois ele apresentou o mesmo erro. Reinstalei então o DW e... nada.

Já sem saída, comecei a utilizar o EditPlus. É um bom editor, entretanto não é tão produtivo para designers quanto o DW, pois não oferece Code Hint, o code coloring não é muito bom, não contém os componentes de Spry, etc.

Ah, sim, o Spry. Já estava quase começando a crer que o problema era com estes componentes. Para quem não conhece, o Spry é um framework de Ajax da Adobe, independente de ferramenta, que possui diversos widgets, efeitos de componentes, etc, semelhantemente a JQuery, Mootools, YUI, entre outros, porém é de fácil aprendizado e utilização. Além disso, o DW CS3 já vem com o framework e reconhece as propriedades dele. Enfim, continuando...

(Estamos quase chegando ao final da odisséia...)

Bom, nesta quarta-feira (17/09), já conformada que não utilizaria mais o programa no PC da empresa, resolvi, apenas por curiosidade, tentar iniciar o DW... e desta vez funcionou! Bom, fiquei sem entender o que tinha ocorrido, mas o que interessava era saber que ele tinha voltado a funcionar. Eis que a primeira coisa que fiz foi trabalhar em uma folha de estilos. Alterei - novamente - o valor de um padding de 10px para 0. Sim, ele parou de funcionar mais uma vez.

Até agora você deve estar pensando que o bug tem a ver com este tipo de alteração. Não, este ainda não é o momento hilário.

Pesquisando um pouco, encontrei um tópico em um Google group oficial do Dreamweaver, em que a Adobe dá suporte a usuários (Dreamweaver CS3 Crashes At Start Up). Já havia acessado esta página anteriormente e visto o link the Troubleshooting recomendado pelo funcionário da Adobe, mas não havia adiantado. Porém, resolvi continuar lendo o tópico.

Pelo relato de várias pessoas, parecia que minhas suspeitas estavam certas: o problema poderia ser o website (projeto) no DW que utilizava Spry ou um bug com esta mudança de padding que eu havia feito, pois ambas situações ocorreram com outros usuários que tiveram o mesmo erro. Outras hipóteses seriam conflitos entre DW e Flash ou ZoneAlarm.

Mas, foi David Powers, autor do livro "The Essential Guide to Dreamweaver CS3", que deu o diagnóstico final:

Pasmem, mas o DW tem um bug em uma DLL, reconhecido pela própria Adobe, que faz com que o programa quebre se você criar um arquivo que seja exatamente 8.192 bytes ou múltiplo deste valor. A solução é mover a pasta do projeto para outro local ou renomeá-la e adicionar mais alguns bytes ao arquivo. Vi o relato de outro usuário que comentou que um arquivo dele possuia 16.384 bytes (exatamente o dobro). Verifiquei a folha de estilo principal, onde eu estava realizando a mudança de paddings e ocasionou a quebra do DW: 16.384 bytes. Não acreditei quando vi isso, caí na gargalhada e meus colegas também não acreditaram quando eu contei. Coloquei algumas linhas a mais no CSS e pronto, funcionou!

Apenas complementando: este erro ocorre principalmente com arquivos CSS (ou somente com eles, não tenho certeza).

Então, fiquem de olho no file size dos seus arquivos quando utilizarem o Dreamweaver ;)

19 pessoas comentaram o post até agora.

10/8/2008

Novas reformulações no blog

Durante o recesso escolar, uma de minhas "lições de casa" foi fazer uma reestruturação do blog. E as mudanças não se restringiram apenas ao layout, melhorei também alguns recursos e até mesmo a performance do site.

Bom, vamos a uma rápida lista de mudanças.

Layout e Arquitetura de Informação

Na versão anterior do blog, não gosto muito do header, principalmente. Então resolvi deixar ele e os outros elementos da página consistentes com a identidade visual do meu portifólio, apenas modificando levemente o estilo. Dessa forma, a associação entre ambos os sites é fortalecida.

Outra grande mudança foi a organização do conteúdo. Os posts agora estão do lado esquerdo, em uma área mais valorizada. A primeira coluna secundária contém links relativos ao conteúdo do blog (feed, bookmark, arquivo, etc.), enquanto que a última coluna é para informações mais pessoais, com um breve perfil sobre o blog e sobre mim, além de links para outros blogs interessantes. A caixa de busca também ganhou nova localização, ficando mais destacada no topo.

Compartilhamento

Resolvi colocar novamente a API de compartilhamento do delicious, que havia ficado de fora da versão anterior por um pequeno lapso de memória.

E o melhor: o famoso widget Add This agorá está presente na página de cada post, facilitando o compartilhamento do conteúdo do blog com o serviço favorito do visitante.

Paginação

Este é um recurso que tem grande impacto sobre a performance. Antigamente, todos os artigos postados até hoje apareciam na página inicial, o que fazia com que o site demorasse muito tempo para carregar. Agora, com os registros paginados, são mostrados apenas 5 posts por página.

Os rótulos de navegação também seguem uma nomenclatura lógica: na página 1 (default) o link ativo é "Anteriores" e não "Próximos", afinal, o visitante deseja ver os posts anteriores. Me baseei em sistemas atuais como o GMail e o Delicious para adotar este padrão.

Espero que todos apreciem as mudanças e enviem seu feedback.

:)

2 pessoas comentaram o post até agora.