Tableless » padroes web http://tableless.com.br Tableless - Desenvolvimento inteligente com padrões web Fri, 18 May 2012 12:22:56 +0000 pt-br hourly 1 http://wordpress.org/?v=3.3.2 Documentos poliglotas com XHTML5 http://tableless.com.br/documentos-poliglotas-com-xhtml5/ http://tableless.com.br/documentos-poliglotas-com-xhtml5/#comments Wed, 16 May 2012 13:35:51 +0000 Talita Pagani http://tableless.com.br/?p=6057 Quando se começou a falar massivamente a respeito do HTML5, em 2009, muitos desenvolvedores (inclusive eu) torceram o nariz para o fato de poder voltar a utilizar a sintaxe tolerante do HTML, ou seja, tags em uppercase ou sem fechamento, valores de atributos sem aspas, fechar tags em ordem incorreta, entre outros. Inclusive, comentei especificamente sobre isso em um outro artigo.

Grande parte dos desenvolvedores aprenderam  e se habituaram a utilizar a sintaxe do XHTML, que segue as diretrizes do XML para documentos bem formados e que apresentariam erros de renderização caso essas diretrizes são fossem seguidas. Isto nos permitia códigos mais limpos e bem estruturados. Porém, no HTML5, a escolha é sua e você não será punido por não fechar tags.

Com toda essa preocupação, no mesmo ano começou a ideia do XHTML5, uma tentativa de contornar o problema, adicionando as restrições de marcação do XML a documentos escritos em HTML5. Podemos dizer que seria uma tentativa de unir o melhor de cada especificação. O artigo escrito por Bruce Lawson para o HTML5 Doctor (com versão traduzida no Pinceladas da Web) foi um dos primeiros a comentar sobre o tema.

Durante cerca de 1 ano isto era uma forma, digamos, marginalizada de tratar essa questão, por não ser algo reconhecido pelo  WHATWG / HTML WG. Mas em 2010 surgiu o primeiro draft com a proposta de nortear o uso do HTML5 com a sintaxe do XML/XHTML. O W3C denominou essa metodologia de marcação poliglota.

O que é um documento com marcação poliglota?

Um documento com marcação poliglota é um documento escrito em HTML5 que pode ser processado tanto como HTML quanto como XML dentro de um conjunto de restrições definidas, porém, ainda seguindo a especificação do HTML5. Eles são compatíveis com o HTML e XHTML.

Significa que você pode utilizar todo o poder do HTML5 dentro do padrão de marcação bem formada do XML. É importante ressaltar que isto não afeta as tags que você pode utilizar. Por exemplo, elementos que são considerados deprecated em XHTML mas válidos no HTML5 continuam a ser válidos. Uma exceção é com relação a algumas tags que são excluídas de documentos poliglotas por não serem possível de serem replicadas em um parser XML (como é o caso da tag <noscript>).

Mas em linhas gerais, esta “fusão” não altera a especificação, mas sim as regras de sintaxe para processamento e há influência no DOM também (ex.: document.write não é permitido, mas sim innerHTML).

Segundo o W3C, um documento poliglota resulta em:

  • Um documento HTML5 válido;
  • Um documento XML bem formado (mas não significa um documento XML válido);
  • DOM idêntico quando processado tanto como HTML quanto como XML, isto porque os parsers geram diferentes DOMs para determinados atributos relativos ao XML.

Como escrever um documento poliglota

Um dos principais requisitos para escrever um documento em XHTML5 é o MIME-type utilizado. Isto vai definir se o navegador irá interpretar o documento como HTML ou XHTML. Segundo o WHATWG, um documento HTML5 se torna um documento poliglota se for provido o MIME-type application/xhtml+xml.

1
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />

Até algum tempo atrás, o IE não suportava este MIME-type. Para isso, você pode indicar que o MIME-type é o usual text/html. Ele pode ser utilizado junto com o primeiro (separando por vírgula), ou pode ser feita uma validação do navegador para decidir qual o MIME-type a ser utilizado.

O doctype passa a ser opcional, mas ainda é recomendável utilizar para prevenir o quirks mode dos navegadores. Se utilizado, a palavra doctype deve ser escrito adequadamente em uppercase, ex.: <!DOCTYPE html>. A meta-tag que especifica o charset e a declaração <?xml version=”1.0” encoding=”UTF-8”?> (herdada do XHTML 1.1) também passam a ser opcionais se o charset desejado para o documento é UTF-8 (padrão do XML).

Além disso é preciso definir também o namespace do XHTML na tag <html>:

1
<html xmlns="http://www.w3.org/1999/xhtml">

Ao utilizar recursos como SVG e MathML, é preciso especificar também o atributo xml para a tag raiz correspondente de cada um.

Outras recomendações são:

  • Usar tanto o atributo lang quanto xml:lang na tag <html>;
  • Usar tbody / thead / tfoot em <table>s;
  • Quando o elemento <col> é utilizado em tabelas, utilizar também o elemento <colgroup>;
  • Não utilizar o elemento <noscript>;
  • Não iniciar as tags <pre> e <textarea> com linha em branco;
  • Utilizar innerHTML ao invés de documento.write;
  • Para scripts embutidos na página, escreva o código entre uma seção CDATA com os delimitadores comentados. É uma forma de fazer com que o parser do XML (que analisa apenas a marcação) não acuse erros ao utilizar < ou & no script;
  • Os atributos xml:space e xml:base são permitidos apenas nos elementos relativos a SVG e MathML;
  • Elementos que podem ter conteúdo mas estão vazios não devem ser minimizados para o formato de tag órfã. Ex.: <p /> não deve ser utilizado, mas sim <p></p>.

Ao escrever documentos poliglotas, é possível utilizar todas as funcionalidades do HTML5 com uma garantia de código bem formado de acordo com as restrições do XHTML. Com isso, é possível ter um código mais organizado e consistente que seja mais fácil de produzir, manter e reutilizar a longo prazo, principalmente quando este trabalho é realizado em equipe.

Referências

Polyglot Markup: HTML-Compatible XHTML Documents
XHTML5 in a nutshell
Benefits of polyglot XHTML5
HTML 5 + XML = XHTML 5

Posts Relacionados

]]> http://tableless.com.br/documentos-poliglotas-com-xhtml5/feed/ 13 Entendendo quais APIs (realmente) fazem parte do HTML5 http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/ http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/#comments Wed, 02 May 2012 12:00:36 +0000 Talita Pagani http://tableless.com.br/?p=5981 Com o HTML5 ganhando força no mercado de desenvolvimento web, maior tem sido o interesse dos desenvolvedores em compreender seus recursos, novas APIs e tecnologias adjacentes. E é aí que acontece uma grande confusão.

Sabemos que o HTML5 não se trata apenas de marcação, mas também de um conjunto de novas funcionalidades encapsuladas em APIs que podem ser acessadas via JavaScript.

Porém, há APIs em processo de padronização pelo W3C que não fazem parte da especificação do HTML5. Elas são especificações relacionadas não intrínsecas ao HTML5, ou seja, a utilização delas não está estritamente atrelada ao uso da linguagem. Algumas, inclusive, faziam parte do core do HTML5, mas hoje estão dissociadas e contam com uma especificação separada, como é o caso do Web Storage.

As APIs próprias do HTML5 são mais específicas às funcionalidades que atuam no escopo da página e da manipulação de elementos. Elas se relacionam em grande parte com o DOM. Já as outras APIs geralmente trabalham com funcionalidades um pouco mais complexas, como armazenamento de dados e manipulação de arquivos, por exemplo.

Algumas das novas APIs que estão contidas na especificação do HTML5 são:

  • Canvas
  • Validação de formulários
  • Controles de áudio e vídeo
  • Application cache / offline applications
  • Funcionalidade de markup editável (contenteditable)
  • Drag and drop
  • Novas funcionalidades para manipulação do histórico do navegador

Algumas das novas APIs que são desenvolvidas em conjunto pelo WHATWG e W3C e trabalham muito bem com HTML5 mas que não são (mais) exclusivas dele:

  • Web Storage (localStorage e sessionStorage)
  • Web messaging
  • Microdata
  • Web Workers
  • Web Sockets

E algumas especificações relacionadas, que não são desenvolvidas pelo WHATWG e possuem especificações publicadas separamente pelo W3C:

  • Geolocation
  • File API
  • Indexed DB
  • File Writer
  • Notifications

O gráfico abaixo, desenvolvido por Sergey Mavrody fornece uma boa visão deste contexto e do relacionamento entre as novas APIs e o HTML, além de mostrar o status de desenvolvimento de cada uma destas especificações. Note que o Web Storage ainda está incluído junto à especificação do HTML5, mas isto já mudou.

HTML5 e as APIs relacionadas

HTML5 e as APIs relacionadas por Sergey Mavrody

Portanto, muitas vezes quando falamos das novas possibilidades do HTML5, na verdade estamos nos referindo à toda uma nova geração de tecnologias para a web.

O que podemos concluir disso tudo é que o HTML5, sozinho, não faz uma web melhor. Porém, ele ajudou a movimentar o mercado rumo ao desenvolvimento de novas tecnologias. Saímos da zona de conforto que já estávamos há alguns anos. O cenário que temos agora é de uma série de tecnologias web que, trabalhando em conjunto, fazem uma web melhor, para as pessoas e para os desenvolvedores ;)

Referências:

Especificação do HTML pelo WHATWG
W3C – HTML5 differences from HTML4
HTML5 – Wikipedia

Posts Relacionados

]]> http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/feed/ 3 As cores da minha web http://tableless.com.br/as-cores-da-minha-web/ http://tableless.com.br/as-cores-da-minha-web/#comments Mon, 02 Apr 2012 21:13:42 +0000 Reinaldo Ferraz http://tableless.com.br/?p=5876 Talvez as cores que eu veja não sejam as mesmas que você enxerga, mas isso não faz com que a sua percepção da web seja diferente. Nesse ambiente tão democrático, nada mais justo do que discutir as diversas formas de perceber as cores da web.

Tenho um grande amigo que sonhava ser piloto de avião. Por trabalhar em uma empresa aérea, a proximidade com as grandes máquinas voadoras o encantava. Porém, seu sonho de pilotar acabou quando, aos trinta anos de idade, ele descobriu que tinha um grau de daltonismo que o impediu de continuar o treinamento.

O mais curioso dessa história foi que ele viveu seus trinta anos anteriores sem saber que enxergava cores de forma diferente das demais pessoas. Seu tipo de daltonismo foi classificado como deuteranopia, que dificultava reconhecer certos tons de verde. A partir dessa descoberta, comecei a estudar como cada pessoa vê as cores da sua web.

Por esse motivo, os cuidados com cores são importantíssimos no desenvolvimento de páginas web. O WCAG 2.0 (Web Content Accessibility Guidelines) é bem direto com relação a isso: A cor não deve ser utilizada como o único meio visual de transmitir informações. Isso significa que você não deve utilizar indicações como “clique no botão verde para continuar” ou, “campos marcados em vermelho são obrigatórios”.

Mas isso não significa que o uso de cores deve ser banido da web. Pelo contrário. O uso de cores e contrastes é um dos maiores atrativos visuais de uma página. O que faz uma página ser bela aos olhos de um usuário é a combinação entre tons e cores. Mas o cuidado com o contraste deve ser considerado, já que pessoas com certos graus de daltonísmo e baixa visão podem ter dificuldade de enxergar alguns contrastes. Por isso mesmo, o E-Mag, modelo de acessibilidade do Governo Eletrônico diz que o mínimo de contraste entre o plano de fundo e o primeiro plano deve ser de 3 para 1. Se você tem dúvidas, na última página do E-Mag existe uma tabela de cores que faz o contraste adequado com preto e branco (já em hexadecimal). No WCAG 2.0, esse valor é de 4,5 para 1.

E quando o daltonismo é tão severo ao ponto de fazer com que a pessoa não enxergue cor nenhuma (somente tons de cinza)? Esse é um tipo de daltonismo raro, mas aconteceu com o artista Neil Harbisson, que esteve na quinta edição da Campus Party Brasil contando como conseguiu resolver seu problema de distinguir cores: implantando uma câmera em seu crânio que identifica as cores e transforma essa informação em áudio. Uma ótima palestra que vale a pena ser assistida.

E por falar em bani-las da web, o que podemos dizer da implementação de cores quando o acesso a página é feito por um software leitor de tela? A primeira recomendação dada pelo WCAG é separar a estrutura do documento da apresentação, ou seja: Formatação visual somente dentro do CSS. Isso quer dizer que o software leitor de tela, que navega pelo código da página HTML, ignora as cores aplicadas no documento? Não!

O software JAWS, popular software leitor de tela, possui uma configuração que permite que o usuário saiba quais as cores ou fontes utilizadas na página, ou mesmo simples combinações de tecla podem permitir que o usuário cego saiba que fonte está sendo usada no site e qual a cor dela.

Isso significa que a minha web tem cor, inclusive para uma pessoa cega que acessa minha página.

Além de todas as diretrizes citadas nesse documento o uso do bom senso é fundamental para termos uma web bela, cheia de cores e que permitam que todos possam navegar por ela. Inclusive aquele meu amigo do início desse texto, que um dia me pediu ajuda para instalar sua televisão nova e não enxergava um tal botão verde no controle remoto que fazia a busca por canais. Felizmente, o termo “pesquisar canais” estava escrito no controle.

Talvez eu não enxergue as cores da mesma forma que você, mas mesmo com essas diferenças a minha web é tão bela quanto a sua deve ser.

Posts Relacionados

]]> http://tableless.com.br/as-cores-da-minha-web/feed/ 13 Seu lugar ao sol http://tableless.com.br/seu-lugar-ao-sol/ http://tableless.com.br/seu-lugar-ao-sol/#comments Mon, 12 Mar 2012 11:45:26 +0000 Diego Eis http://tableless.com.br/?p=5682

Você realmente acha que vai escrever CSS e HTML como escreve hoje em um cenário como este?
Você já parou para pensar onde CSS/HTML e Javascript se encaixam em um ambiente onde a web é praticamente camuflada por APPs específicos? Eu não estou me referindo a estes Apps como conhecemos hoje. Podem ser Apps instaladas ou WebApps, neste futuro, dá na mesma. Não há diferença.

Pior do que pensar o lugar que CSS e HTML estarão é pensar em como VOCÊ se colocará em um ambiente tão novo quanto este. O que realmente iremos fazer? Qual será o papel de cada um? Será que a metodologia de trabalho será a mesma?

Você também já deve ter visto o vídeo acima. Veja como os personagens utilizam seus gadgets e como tudo está sincronizado. A discussão aí não é se é melhor criar uma App ou uma aplicação Web, é se o seu produto é realmente relevante e se vai ajudar realmente a vida das pessoas. A forma como isso é oferecido não importa, porque em um cenário como esse tudo é igual. Não faz diferença nenhuma. A Web não é só o seu browser.

É por isso que eu acho que os desenvolvedores precisam acordar. Urgente.
Eu perco as contas de quantos desenvolvedores me castigam quando eu digo para ignorar totalmente os browsers antigos. Você acha que um futuro como mostrado nos vídeos ou qualquer outro tipo de futuro, vai ficar esperando um browser ser adequado aos padrões? Aliás, browsers existirão?

Você precisa repensar o que realmente é vida digital. Qual a real utilidade de se carregar um celular dispositivo móvel. Repense o que será design responsivo. Eu sei que a necessidade de hoje é adaptar websites e aplicações para as diversas telas, mas entende que isso é só uma necessidade que vai passar rápido? Vai passar rápido não porque é uma modinha sem importância, mas porque isso deverá ser padrão daqui pra frente. Assim como o Tableless. Lembra que falavam que isso era uma modinha e que já já passaria? Pois é.

Experimente fazer o exercício de entender o futuro da web. É algo que todo profissional web deveria fazer, principalmente os desenvolvedores. Não importa qual linguagem de programação você vai precisar aprender ou desaprender, o que importa é como ela será aplicada. Isso muda tudo.

Embora a ideia não seja apenas direcionada a Mobile mas para todos os meios de acesso, vale muito a pena ver a apresentação que o Michel Lent fez. Dá uma olhada:

Repensando o marketing a partir do mobile

Posts Relacionados

]]> http://tableless.com.br/seu-lugar-ao-sol/feed/ 15 Experiência deve ter começo, meio e fim http://tableless.com.br/experiencia-deve-ter-comeco-meio-e-fim/ http://tableless.com.br/experiencia-deve-ter-comeco-meio-e-fim/#comments Mon, 28 Nov 2011 23:55:31 +0000 Diego Eis http://tableless.com.br/?p=4549 Esse artigo pode parecer meio confuso, mas é apenas um pensamento que estive matutando. Não ligue se a ordem das ideias estiverem tortas e sinuosas. ;-)

Tive uma experiência muito ruim no primeiro dia de 2010: pulei na piscina com meu iPhone no bolso.
Ok, pode me xingar agora.

Depois da tragédia, ele durou rápidos 5 segundos, e faleceu. Não ligava, não apitava, não fazia nada. “Paciência”, falei para mim mesmo. No dia seguinte peguei um celular reserva que eu tinha guardado: um HTC Touch, com Windows Mobile 6 (não Windows Phone). Foi então que eu notei o porque o trabalho da Apple vicia os consumidores.

Estamos bem acostumados a utilizar um notebook ou um computador desktop, com monitor, teclado e mouse. A interface do sistema muitas vezes parece desaparecer quando se abre o navegador. A experiência de uso dos periféricos já é bastante conhecida e isso facilita muito a forma com que o usuário interaje com a interface. Há uma harmonia, se é que você me entende. A mesma coisa é dificil de acontecer quando utilizamos um dispositivo mobile. Em um dispositivo móvel você precisa de foco. Não há espaço para milhares de botões com dezenas de ações. É SIM e NÃO. É OK ou CANCELAR e mais nada. O que não é o caso do Windows Mobile. O Windows Mobile foi feito daquele jeito Microsoft. Muito, mas muito diferente do Windows Phone que está um primor. Com uma interface totalmente repensada, do zero, onde seu visual se integra com os outros sistemas da marca. Há uma homogeneidade na experiência do usuário quando ele usa a Live do XBOX, o Windows Phone e o Windows 8. A experiência é cross-platform. A Apple faz isso durante anos. E durante todos estes anos esse foi seu segredo. O famoso “eco sistema Apple”. Tudo funciona muito bem quando estamos com nossos iPhones, iPads, MacBooks e iPods. Se eu tenho um iPad, mas utilizo um PC, algo fica estranho. Funciona, mas fica estranho.

Assim como sistema dos mobiles, os sites precisam seguir a mesma fórmula de simplicidade e foco. Por isso, criar sites para mobiles é uma arte. É um jogo de prioridades. Você precisa saber o que é importante na página e focar naquilo. Há um bom trabalho de arquitetura de informação que precisa ser feito. E não se engane, as vezes é muito mais dificil desenvolver um projeto de arquitetura para mobiles do que para versões full.

O iPhone, e agora o Windows Phone, se destacam muito por conta dessa harmonia que citei acima. Há uma ligação em tudo ali. Quando você aciona o Safari, ele tem uma interface intuitiva, bem acabada e que não agride a usabilidade do site. O iPhone tem um browser 100% atualizado com os Padrões Web e isso ajuda um bocado o desenvolvimento de interfaces inteligentes.
E a Apple se preocupa com essa harmonia da qual estamos falando, ela prepara uma série de materiais que ajudam os desenvolvedores. São guias de desenvolvimento e referência com os princípios de design e usabilidade que garantem a experiência completa. Por causa disso os desenvolvedores e designers fazem ótimos apps, tornando a experiência do usuário completa e uniforme durante o uso do dispositivo.

É por isso que a vale a pena municiar os desenvolvedores e designers do mundo todo, para que a experiência não termine quando o consumidor feche o seu aplicativo ou abra o navegador. Experiência tem começo, meio e fim. A Apple se preocupa com essas etapas. Ela sabe que se o site abrir “quebrado” o consumidor vai xingar primeiro o aparelho e não site. Tudo é uma única experiência. Começa no sistema do aparelho e termina no site de um terceiro.

O resto dos aparelhos começam pecando por ter um browser ruim ou uma interface de uso complicada. Na maioria os browsers não dão suporte algum aos Padrões. Isso é um pecado. Se eu tenho um Smartphone, eu passarei mais tempo na internet, conectado, do que falando ao telefone. Esse é apenas um ponto sobre o porque um dispositivo móvel precisa ter um browser decente.

O usuário tem uma boa experiência quando consegue com sucesso a informação que procurava, sem bloqueios. Se ele consegue passar esse processo com sucesso, como se o dispositivo (mobile, desktop, notebook, leitor e tela etc) e o site/sistema fossem transparentes, aí cumprimos com o nosso dever.

Posts Relacionados

]]> http://tableless.com.br/experiencia-deve-ter-comeco-meio-e-fim/feed/ 9 O que é Usabilidade? http://tableless.com.br/o-que-e-usabilidade/ http://tableless.com.br/o-que-e-usabilidade/#comments Mon, 22 Aug 2011 21:44:42 +0000 Talita Pagani http://tableless.com.br/?p=3823 Já vimos em um artigo anterior como a usabilidade beneficia o desenvolvimento web. Mas, o que de fato compreende a usabilidade? Nem tudo que se refere à experiência de uso está dentro do escopo dela. Sim, a usabilidade tem limitações e lacunas que são complementadas por outros paradigmas, como o design de interação. Porém, podemos considera-la a base da pirâmide que sustenta o projeto de uma aplicação com boa experiência de uso.  Neste artigo, veremos brevemente o que faz parte do conceito de usabilidade e qual o papel que ela tem no processo de desenvolvimento de aplicações.

Afinal, o que é usabilidade?

A Usabilidade é “filha” da Interação Humano-Computador (IHC) e “neta” da Engenharia de Software, carregando esse legado ao longo de sua evolução, podendo ser definida como o grau de facilidade com que o usuário consegue interagir com determinada interface.

Partindo da IHC, a usabilidade aborda a forma como o usuário se comunica com a máquina e como a tecnologia responde à interação do usuário, considerando as seguintes habilidades, de acordo com a norma ISO 9241:

  • Facilidade de aprendizado: a utilização do sistema requer pouco treinamento;
  • Fácil de memorizar: o usuário deve lembrar como utilizar a interface depois de algum tempo;
  • Maximizar a produtividade: a interface deve permitir que o usuário realize a tarefa de forma rápida e eficiente;
  • Minimizar a taxa de erros: caso aconteçam erros, a interface deve avisar o usuário e permitir a correção de modo fácil;
  • Maximizar a satisfação do usuário: a interface deve dar-lhe confiança e segurança.

Partindo da Engenharia de Software, a usabilidade é englobada dentro da qualidade e visa garantir uma parte da eficiência e eficácia do sistema. A eficiência refere-se a uma interação produtiva entre o usuário e o sistema, permitindo a realização de tarefas com menor esforço sob uma experiência agradável. A eficácia pode ser entendida como a capacidade do sistema e da interface possibilitarem ao usuário a completude da tarefa e o alcance de seus objetivos no sistema.

A importância da usabilidade no desenvolvimento de projetos

A usabilidade se encaixa em qualquer tipo de projeto de interface, tendo amplitude diferente de acordo com a criticidade do projeto, ou seja, quanto mais crítico for o sistema, maiores serão as perdas caso ele não seja de fácil utilização e proporcione satisfação. Ela deve ser pensada desde o planejamento do projeto, até a etapa de desenvolvimento e teste.

As empresas têm consciência da importância da usabilidade. Porém, muitas ainda a veem como um fator que só deve ser levado em conta durante o desenvolvimento se houver tempo e recurso, como se ela representasse um custo adicional, fora do que é essencial. Mas as empresas têm muito mais a perder ao minimizar a usabilidade dessa forma. De acordo com Cybis, Betiol e Faust (2007):

“Dependendo da frequência com que o software é empregado, os prejuízos para as empresas podem também ser expressivos, não só em decorrência do absenteísmo e da rotatividade do pessoal, mas também pela baixa produtividade, competitividade e menor retorno de investimento. Sistemas difíceis de usar implicam em erros e perda de tempo, fatores que se multiplicam com a frequência das tarefas e o número de usuários. A perda de dados e informações pode implicar na perda de clientes e de oportunidades. Acontecimentos deste tipo causam desde uma resistência ao uso do sistema até a sua subutilização e abandono completo, com o devido consentimento da empresa. O barato terá custado caro.”

A usabilidade pode ser abordada de diferentes formas ao longo do projeto:

Técnicas utilizadas para garantir e verificar a usabilidade em diferentes etapas

Técnicas utilizadas para garantir e verificar a usabilidade em diferentes etapas

Lacunas a serem preenchidas

Apesar de a usabilidade ser responsável por assegurar grande parte dos quesitos de experiência do usuário, ela possui duas grandes limitações:

  1. Embora considere a satisfação do usuário, trata apenas dessa satisfação perante a realização de uma determinada tarefa, concentrando-se na função, sem considerar fatores físicos, ambientais e emocionais inerentes ao contexto de utilização do sistema. Mais do que ser de fácil utilização, aprendizagem e permitir completude da tarefa, uma boa experiência de uso está baseada em uma interação agradável, considerando a forma como as pessoas percebem a interação com o sistema;
  2. O contexto usualmente analisado pela usabilidade é mais restrito: abrange apenas a visão do usuário. Para garantir uma boa experiência de uso, é necessário abranger a visão de diferentes stakeholders: do usuário, da organização e da equipe de desenvolvimento, cada qual com requisitos e necessidades diferentes frente ao sistema.

Adaptando um gráfico apresentado durante a nnGroup Conference de 2008, podemos ver a usabilidade enquadrada da seguinte forma:

O escopo da usabilidade

O escopo da usabilidade

Referências e Leitura Complementar

ABRAS, C.; MALONEY-KRICHMAR, D.; PREECE, J. User-Centered Design. In: Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications, 2004.

CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos, Métodos e Aplicações. São Paulo: Novatec Editora, 2007. 344p.

SUMATHI, B. Chapter Three: User Centered Design Approach. Disponível em: http://dspace.fsktm.um.edu.my/bitstream/1812/214/8/Chapter%20Three.pdf.

NIELSEN, J.; LORANGER, H. Usabilidade na Web: Projetando Websites com qualidade. Rio de Janeiro: Elsevier, 2007. 406p.

OLIVEIRA NETTO, A. A. IHC – Interação Humano Computador: Modelagem e Gerência de Interfaces com o Usuário. Florianópolis: VisualBooks, 2004. 120p.

PREECE, J.; ROGERS; Y.; SHARP, H. Interaction Design: Beyond Human-Computer Interaction. New York: John Wiley & Sons, Inc., 2002. 551p.

ROCHA, H. R.; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humano-Computador. Campinas: Universidade Estadual de Campinas, 2007.

UX Revisions. The Difference Between Usability and User Experience. Disponível em: http://www.uxrevisions.com/user-experience-design/the-difference-between-usability-and-user-experience/18/

UX Revisions. User Experience vs User Interaction. Disponível em: http://www.uxrevisions.com/user-experience-design/user-experience-vs-user-interaction/16/

Usability Geek. The Difference (And Relationship) Between Usability And User Experience. Disponível em: http://usabilitygeek.com/the-difference-between-usability-and-user-experience/

NeoSpot. Usability vs. User Experience (UX). Disponível em: http://neospot.se/usability-vs-user-experience/

Interaction by Design. Usability vs. user experience. Disponível em: http://www.interactionbydesign.com/thoughts/thumbnails/00000050.html

Posts Relacionados

]]> http://tableless.com.br/o-que-e-usabilidade/feed/ 12 CSS3 – Breve introdução ao RGBA http://tableless.com.br/css3-breve-introducao-a-rgba/ http://tableless.com.br/css3-breve-introducao-a-rgba/#comments Mon, 02 May 2011 13:18:56 +0000 Diego Eis http://tableless.com.br/?p=3682 Introdução ao RGB

Normalmente em web trabalhamos com cores na forma de hexadecimal. É a forma mais comum e mais utilizada desde os primórdios do desenvolvimento web. Mesmo assim, há outros formatos menos comuns que funcionam sem problemas, um destes formatos é o RGB. O RGB são 3 conjuntos de números que começam no 0 e vão até 255 (0% até 100%), onde o primeiro bloco define a quantidade de vermelho (Red), o segundo bloco a quantidade de verde (Green) e o último bloco a quantidade de azul (Blue). A combinação destes números formam todas as cores que você pode imaginar.

No HTML o RGB pode ser usado em qualquer propriedade que tenha a necessidade de cor, como: color, background, border etc. Exemplo:

1
2
3
4
5
    p {
        background:rgb(255,255,0);
        padding:10px;
        font:13px verdana;
    }

Este código RGB define que o background o elemento P será amarelo.

Aplicando o RGBA e a diferença da propriedade OPACITY

Até então nós só podíamos escrever cores sólidas, sem nem ao menos escolhermos a opacidade dessa cor. O CSS3 nos trouxe a possibilidade de modificar a opacidade dos elementos via propriedade opacity. Lembrando que quando modificamos a opacidade do elemento, tudo o que está contido nele também fica transparente e não apenas o background ou a cor dele. Veja o exemplo e compare. É aí que entra o RGBA.

O RGBA funciona da mesma forma que o RGB. No caso do RGBA, além dos 3 canais RGB (Red, Green e Blue) há um quarto canal, A (Alpha) que controla a opacidade da cor. Nesse caso, podemos controlar a opacidade da cor de background, borda, color ou qualquer propriedade que contenha cor sem afetar a transparência dos outros elementos:

Veja um exemplo aplicado abaixo:

1
2
3
4
5
    p {
        background:rgba(255,255,0, 0.5);
        padding:10px;
        font:13px verdana;
    }

O último valor é referente ao canal Alpha, onde 1 é totalmente visível e 0 é totalmente invisível. No exemplo acima está com uma opacidade de 50%.

Como o Hexadecimal, você não precisa decorar todos estes números. Hoje, qualquer programa gráfico já dá o código do RGB da cor utilizada. O Hexadecimal não foi descontinuado. Se caso você tenha alguma cor que não ficará transparente ou algo do tipo, você pode continuar utilizando hexa e para aqueles que tem transparência, você pode utilizar o RGBA sem problemas.

Veja novamente o exemplo aqui e o código no github do Tableless.

Posts Relacionados

]]> http://tableless.com.br/css3-breve-introducao-a-rgba/feed/ 15 Manipulando a metatag Viewport http://tableless.com.br/manipulando-metatag-viewport/ http://tableless.com.br/manipulando-metatag-viewport/#comments Mon, 18 Apr 2011 13:00:09 +0000 Diego Eis http://tableless.com.br/?p=3540 O viewport é a área onde seu website aparece. É a área que você se preocupa se o vai ou não caber na hora da criação. O tamanho do viewport depende muito da resolução, tamanho do monitor e dispositivo utilizado. Em máquinas desktop nós não precisamos nos preocupar muito, já estamos acostumados com um determinado tamanho de tela e resolução média utilizada pelos usuários, que hoje gira em torno de no mínimo 1024 de largura. Mas quando começamos a variar muito o tamanho das telas, a largura do viewport começa a ser uma preocupação porque afeta diretamente a forma como o usuário utiliza seu website.

Hoje existe uma gama muito grande de aparelhos com telas de tamanhos variados. Comece a pensar pelos netbooks e depois vá diminuindo até chegar em um smartphone popular como iPhone, Milestone e etc. A variação de tamanho de tela é muito grande. Lembrando que o tamanho da tela é uma coisa e a resolução de tela é outra. Nunca confunda os dois. A largura da tela do iPhone na posição retrato é de 320px. Mas sua resolução padrão é 980px. Isso quer dizer que se você fizer um HTML simples, colocar uma imagem de 980px de largura e visualizar no iPhone, não existirá barra de rolagem. Obviamente a imagem ficará miniaturizada, como mostra abaixo:

Isso é interessante porque possibilita a boa visualização de websites que não estão preparados para mobiles. Vemos o site inteiro miniaturizado, com possibilidade de fazer zoom em qualquer parte do layout.

A tag meta viewport

Mesmo assim os smartphones tem telas pequenas podem dificultar a leitura se fizermos um sistema planejado para grandes resoluções. Por isso é interessante que possamos customizar o viewport para que ele se adeque a realidade desses dispositivos. É aí que entra a metatag viewport.
Com essa metatag iremos customizar a resolução inicial que o browser deve renderizar do viewport do dispositivo. Dessa forma, podemos preparar websites com resoluções personalizadas para smartphones e outros aparelhos.

A sintaxe é muito simples e deve ser colocada, como sempre, na tag head:

1
    <meta name="viewport" content="">

Os valores de content são os que seguem abaixo:

Valor Descrição
width Define uma largura para o viewport. Os valores podem ser em PX ou “device-width”, que determina automaticamente um valor igual a largura da tela do dispositivo.
height Define uma altura para o viewport. Os valores podem ser em PX ou “device-height”, que determina automaticamente um valor igual a altura da tela do dispositivo.
initial-scale Define a escala inicial do viewport.
user-scalable Define a possibilidade de o usuário fazer “zoom” em um determinado lugar da tela. É ativado quando o usuário bate duas vezes com o dedo em um lugar da tela.

Como usar

A tela abaixo não tem nenhuma tag de viewport definida.

Veja que o texto do elemento está bem pequeno. Isso é porque estamos visualizando-o em 980px de resolução em uma tela de smartphone.
Vou acrescentar a seguinte linha:

1
    <meta name="viewport" content="width=320px">

Define que a largura do viewport será 320px. O resultado está abaixo:

Se inserirmos uma imagem ou um objeto maior que a largura do viewport, uma barra de rolagem é criada. Não precisa se preocupar com o espaço da barra, já que pelo menos nos OSs de smartphones novos, como iPhone e Android, a barra fica invisível e só aparece pro cima dos elementos.

Adicionando o initial-scale com o valor de 1.5, temos um aumento na escala da visualização. Abaixo segue um exemplo comparativo. A imagem inserida tem 320px de largura, logo ela ficará bem justa na tela quando a escala é 1.0, e um pouco estourada quando a escala é 1.5 ou maior. Veja:

Agora com escala de 1.5:

Agora com escala de 2:

E agora com texto, nas mesmas proporções:



Se colocarmos o user-scalable como NO, desabilitamos a possibilidade do usuário de fazer zoom quando ele bate duas vezes com o dedo. Deixar habilitado o zoom é interessante utilizar quando o viewport não está sendo customizado. No nosso caso aqui, isso não iria adiantar muita coisa, já que todos os elementos estão com o tamanho natural, por isso vamos desabilitá-lo.

1
    <meta name="viewport" content="width=320px, user-scalable=no">

Atente-se para o detalhe de colocar , (vírgula) entre um valor e outro.
Veja um exemplo aqui. Tente ver com um smartphone como o iPhone, Android, etc.

Manipular o Viewport nos dá possibilidades para personalizar o visual de qualquer site para praticamente qualquer dispositivo, não importa sua resolução ou seu tamanho de tela. Quando unimos isso às media queries, temos um outro mundo de possibilidades.

Posts Relacionados

]]> http://tableless.com.br/manipulando-metatag-viewport/feed/ 10 Novo parser HTML5 – FF4 http://tableless.com.br/parser-html5-firefox4/ http://tableless.com.br/parser-html5-firefox4/#comments Mon, 28 Mar 2011 13:00:08 +0000 Diego Eis http://tableless.com.br/?p=3317 O Firefox é o meu browser favorito embora não seja meu browser padrão atualmente. Durante muito tempo ele me segurava com suas extensions exclusivas. Os outros browsers demoraram para ter uma coleção aceitável de extensions que realmente competissem com as do Firefox.
Foi lançado na semana passada o Firefox 4.0 que trouxe uma série de mudanças interessantes. Uma das atualizações mais importantes foi o “redesign” do parser de HTML5.

HTML5 parser

O parser do Firefox 4 foi todo reescrito para melhorar a performance e eficiência da renderização de código client-side. O motor antigo – de 1998 – foi descontinuado e agora com esse novo parser temos a possibilidade de utilizar SVG e MathML diretamente nas páginas HTML5 sem a utilização de namespace de XML. Entre outros diversos bugs que foram arrumados.

A esse novo parser foi escrito baseando-se na especificação do HTML5, que foi a primeira especificação que explica exatamente como os fabricantes de browsers devem ler e renderização o HTML. Estes detalhes técnicos não eram ditos nas versões anteriores das especificações do HTML. Basicamente o antigo HTML era ainda definido nos termos do antigo SGML. Isso implica na relação do código HTML e DOM. Isso quer dizer que o parseador consegue ler melhor a estrutura do nosso HTML e suas hierarquias. Claro, toda a performance do paseador é somente utilizada se o código for bem escrito e não tiver erros de sintaxe. A grande maioria dos sites na web ainda utilizam códigos mal escritos em HTML4. Leia mais sobre o DOM.

Para os casos onde o HTML for mal escrito, como em sites antigos que foram criados para suprir necessidades de browsers como Netscape e IE, o parser faz uma mudança de interpretação fazendo com que o Firefox entenda esse código antigo e não quebre o site. Logo, não precisamos manter um legado com códigos antigos e abre portas para a criação de código novo, mesmo estando em ambientes onde ainda é necessário conviver com código antigo.

MathML e SVG

Uma das vantagens desse novo parser é que ele permite que você sirva MathML e SVG diretamente na sua página sem ter que declarar a página inteira como XML/XHTML. Isso quer dizer que o código abaixo pode ser inserido normalmente em uma página HTML, sem qualquer namespace declarado.

Veja um exemplo de MathML:


  x

  =
  
    
      −
      b
      ±
      
        

          b
          2
        
        −
        4
        &InvisibleTimes;
        a

        &InvisibleTimes;
        c
      
    
    
      2
      &InvisibleTimes;
      a

Veja o exemplo online.
Veja o código no Github.

Com o SVG é a mesma coisa, veja o código abaixo:

Veja o código acima em ação no nosso GITHUB.

Perceba que os códigos acima se parecem muito mais com um HTML do que com um XML. Perceba que não há nenhum namespace declarado. Isso é uma maravilha porque dá flexibilidade.

Pela explicação do Mozilla Hacks, o algoritmo é dividido em duas partes principais: tokenization e tree building (mantive o termo original porque a tradução literal seria muito estranha). A tokenization (algo como tokenização. Viu, falei que seria estranho) seria o processo de ler o fluxo do código de tags, comentários e atributos de tags. A tree building seria o processo de pegar essas informações encontradas pela tokenização e construir a árvore de tags, o árvore do DOM. O fluxo de tags que você construiu.

Outras atualizações

O Firefox 4 trouxe outras atualizações que podemos falar mais pra frente aqui no Tableless. São atualizações que navegadores Webkit já tem suporte e também o Opera, como: CSS Transitions, Formulários em HTML5, Audio Data API, History API, HTML5 Video buffered property, e o tão aguardado JägerMonkey o novo engine de Javascript da Mozilla.

Posts Relacionados

]]> http://tableless.com.br/parser-html5-firefox4/feed/ 5 Convertidos do Tableless http://tableless.com.br/convertidos-tableless/ http://tableless.com.br/convertidos-tableless/#comments Mon, 21 Mar 2011 04:47:10 +0000 Diego Eis http://tableless.com.br/?p=3293 Quem acompanha o Tableless desde o começo conhece a história de como este humilde website nasceu. Eu estudava e aprendia CSS com HTML de uma única maneira: praticando. Eu convertia para tableless a home de alguns grandes sites just for fun. Só para provar que a técnica era real, possível e muito melhor que tabelas. O Tableless nasceu quando eu decidi compartilhar este material para outros desenvolvedores.

Este material não estava publicado porque uma das empresas que eu utilizei como estudo me mandou uma simpática carta extrajudicial dizendo que eu estava fazendo cópia indevida e todo aquele blá blá blá e que eu devia tirar o materia deles imediatamente do ar… Eles com certeza não eram bem humorados. Com medo de outras empresas fazerem o mesmo, tirei logo todos os exemplos publicados.

Neste fim de semana estava jogando algumas coisas fora e encontrei um CD com alguns documentos destes websites convertidos. Você pode verificar e baixar os arquivos nesta página. Até segunda ordem.

Atenção:

Se você é um troll babaca que vai analisar o código só para criticar como foi feito, entenda que o código mais antigo é de pelo menos uns 6 ou 7 anos atrás… Eu faria tudo diferente. ;-)

Se você pertence a alguma empresa listada nos exemplos, tenha em mente que esse material é utilizado apenas para estudo.

Posts Relacionados

]]> http://tableless.com.br/convertidos-tableless/feed/ 22