Otimização e eliminação de código com webpack e Babeljs

Com a velocidade a qual o javascript avança, tendo versões anuais acrescentando funcionalidades, acabamos por adicionar um compilador (Babeljs o mais comum deles) em nosso workflow para usufruirmos de todas essas novidades e mantermos a compatibilidade, e isso não tem problema nenhum.

Junto ao compilador é comum usarmos também um bundler que se encarrega de gerar nosso código final aplicando diversas otimizações. O webpack é um dos mais conhecidos bundlers javascript atualmente, e ele por si só já oferece várias opções de otimização, mas temos que estar atentos às nossas configurações.

O webpack oferece uma funcionalidade chamada tree shaking. Ela é responsável por eliminação de código não utilizado no nosso bundle. Porém, com a utilização do babel-loader, precisamos configura-ló corretamente para não perder essa funcionalidade.

Como exemplo, vamos entender qual é o problema, para depois entendermos a solução.

Aqui basicamente é um exemplo com módulos javascript

Arquivo module.js

export const say = () => console.log('Say something')

export const scream = () => console.log('SCREAM SOMETHING')

Arquivo index.js

import { scream } from './module.js'

scream()

No index.js importamos somente a função scream do arquivo module.js. Como nossa aplicação não usa a função say, não faz sentido adicioná-la ao nosso bundle, e é isso o que faz o tree shaking do webpack. Porém nosso módulo utiliza algumas coisas que precisam ser compiladas pelo Babeljs para não preocuparmos com retrocompatibilidade, e é ai que temos que ter cuidado.

Geralmente nossa configuração do Babeljs é essa:

{
  "presets": ["env"]
}

A única mudança que precisamos é setar o modules para false.

{
  "presets": [
    [
      "env",
      {
        "modules": false
       }
     ]
  ]
}

O que acontece é que o Babeljs compila o arquivo antes do webpack, e ele converte os módulos para CommonJS por default, e quando chega no webpack ele não consegue usufruir dos módulos nativos do javascript.

Esse é um exemplo simples, mas quando sua aplicação cresce e utiliza muitas libs, não faz sentido onerar muito o carregamento com código não utilizado.

Agora uma outra dica: muitos dos presets do Babeljs possuem um parâmetro chamado loose, e o babel-preset-env é um deles. Basicamente o que acontece na compilação do Babeljs é que quando ele encontra uma funcionalidade não suportada na versão es5, ele compila essa parte do código para es5 mantendo a funcionalidade e semântica do código fonte no código compilado. O que o loose mode faz é compilar para es5, porém não se importando tanto para a semântica, e muitas vezes ele gera um código muito menor. Como o nosso bundle vai ser interpretado diretamente no navegador ou no nodejs, não precisamos nos importar tanto com a semântica aqui, já que continuamos dando manutenção no arquivo fonte.

Para habilitar

{
  "presets": [
    [
      "env",
      {
        "modules": false,
        "loose": true
       }
     ]
  ]
}

Para alguns exemplos de código gerado pelo loose mode leia Babel: Loose mode.

Boas práticas e automatização de tarefas no Front-end

Palestra onde apresento boas práticas de desenvolvimento para o front-end.

Links

Environment setting tutorial Ionic + Android on windows

This post will reply to a request made by a dev who accessed my talk Aplicativos híbridos com Ionic. Você também pode começar a desenvolver agora! (Hybrid applications with Ionic.You can also start developing now!). He was unsure of how to set up the environment to develop for Android.

So let’s get right down to business.

  1. Of course we need the Ionic and Apache Cordova, if you have not installed them, let’s do it.
  2. With the Node installed, now we open the terminal and install the Ionic and Cordova.
    • Run the command
      npm install -g cordova ionic.

      Instalação do Ionic e do Cordova

  3. We begin setting up the environment for Android. We will install the Java JDK.
    • Access the link http://www.oracle.com/technetwork/java/javase/downloads/index.html, select JDK download, download the version compatible with your OS (32 or 64 bits). See the path where you installed, it will be needed at the next step.
    • Now let’s create the JAVA_HOME variable in the Windows environment. Open the System screen using the “windows + pause / break” or go to “Control Panel / System and Security / System”.
    • Click “Advanced System Settings”.
    • Select Environment Variables.
    • Select New environment variable.
    • In the new window, in the name of the variable place JAVA_HOME, and in the value put the path where you installed the JDK. For example, C:\Program Files\Java\jdk1.8.0_65. Click OK.
    • Configurando Variável Java Windows
    • Select the path variable, and click edit. Again, a window will open with the variable data. In the variable field values, go to the end of the string and add  ;%JAVA_HOME%\bin. Do not forget the “;”.
      Adicionando Bin do Java nas Variáveis Ambiente
  4. With Java configured, now we need the Apache Ant, responsible for making the build of our application. Download at the link http://ant.apache.org/bindownload.cgi.
    • After finished downloading, extract the directory to the root of C:.
    • Again we need to update the path variable to add the Ant. Open the environment variables from Windows again.
    • Abra as variáveis de ambiente do windows novamente.
    • Select Environment Variables.
    • Select the path variable and click edit.
    • Add the path to the bin directory of the Ant, for example, ;C:\apache-ant-1.9.6\bin. Again, do not forget the “;”.
      inserindo-ant-variavel-ambiente
  5. The next step is to install the Android SDK, the API that provides libraries and tools required to build, test and debug Android.
    • Download in http://developer.android.com/sdk/index.html#Other, select the .exe (Recommended).
    • Once installed, we need to create the variable ANDROID_HOME, necessary for Cordova. Again, open the environment variables from Windows.
    • Select Environment Variables.
    • Click New.
    • In the new window, in the name of the variable place ANDROID_HOME, and in the variable value put the path to the android-sdk folder you just installed, for example: C:\Android\android-sdk. Click OK.
    • Variável ANDROID_HOME
    • Returning to the environment variables, select the variable path, and click edit. In the new window in the variable value field, go to the end of the string and add ;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools.
    • We’re almost there, now we need to install the android packages. Open SDK Manager.exe file, located inside the android-sdk folder.
    • By default the Tools/Android SDK Tools is already installed. If for some reason it is not marked as installed, select it. Also, select Tools/Android SDK Platform-tool, Tools/SDK build-tools (a version above 22), and select the same API version that you selected in the Build Tools. Also mark Extras/Google USB Driver (required to debug directly on the device), and click install.androi-sdk-manager-panel
    • At the end of the installations our environment is set up.
  6. Let’s do the test. Returning to our application, open the application directory for the terminal and add the android platform.
    • Run
      ionic platform add android

      ionic-add-platform-android

  7. Let’s build our .apk.. Run
    ionic build android

    build-androi-ionic

    • After finishing the process, the path of the generated .apk is displayed in the terminal.
  8. We can also debug the application directly on the device. Plug the device via USB cable, make sure you have enabled the USB debugging, and run
    ionic run android

    run-android

That’s it, Good luck and good development.

Tutorial de configuração do ambiente Ionic + Android no Windows

Esse post vai em resposta à um pedido feito por um dev que acessou minha palestra Aplicativos híbridos com Ionic. Você também pode começar a desenvolver agora!. Ele ficou em dúvida de como montar o ambiente para desenvolver em Android.

Então, vamos direto ao que interessa.

  1. Logicamente precisamos do Ionic e o Apache Cordova, se ainda não os instalou, vamos lá.
  2. Com o Node instalado, agora vamos abrir o terminal e instalar o Ionic e o Cordova.
    • Execute o comando
      npm install -g cordova ionic.

      Instalação do Ionic e do Cordova

  3. Iniciaremos a configuração do ambiente para Android. Vamos instalar o Java JDK.
    • Acesse o link http://www.oracle.com/technetwork/java/javase/downloads/index.html, selecione JDK download, faça o download da versão compatível com seu SO (32 ou 64 bits). Veja o path de onde você instalou, será necessário no próximo passo.
    • Agora vamos criar a variável JAVA_HOME no ambiente do windows, abra a tela de sistema com as teclas “windows + pause/break” ou vá em “painel de Controle / Sistema e Segurança / Sistema”.
    • Clique em “Configurações avançadas do sistema”.
    • Selecione Variáveis de ambiente.
    • Selecione Nova variável de ambiente.
    • Na nova janela, em nome da variável coloque JAVA_HOME, e no valor coloque o caminho onde você instalou o JDK. Por exemplo, C:\Program Files\Java\jdk1.8.0_65. Dê OK.
      Configurando Variável Java Windows
    • Selecione a variável path, e clique em editar. Novamente irá abrir uma janela com os dados da variável, no campo valores da variável, vá até o final da string e adicione ;%JAVA_HOME%\bin. Não se esqueça do “;”.
      Adicionando Bin do Java nas Variáveis Ambiente
  4. Com o Java configurado, agora precisamos do Apache Ant, o responsável por fazer o build de nosso aplicativo. Faça o download no link http://ant.apache.org/bindownload.cgi.
    • Após concluído o download, extraia o diretório para a raiz de C:.
    • Mais uma vez precisamos atualizar a variável path para acrescentar o Ant. Abra as variáveis de ambiente do windows novamente.
    • Selecione Variáveis de ambiente.
    • Selecione a variável path e clique em editar.
    • Acrescente o caminho até a pasta bin do Ant, por exemplo ;C:\apache-ant-1.9.6\bin. Mais uma vez não se esqueça do “;”.
      inserindo-ant-variavel-ambiente
  5. O próximo passo é a instalação do Android SDK, a API que fornece as bibliotecas e ferramentas necessárias para build, teste e debug para Android.
    • Faça o download em http://developer.android.com/sdk/index.html#Other, selecione o .exe (Recommended).
    • Após instalado, precisamos criar a variável ANDROID_HOME, necessária para o Cordova. Mais uma vez abra as variáveis de ambiente do windows.
    • Selecione Variáveis de ambiente.
    • Clique em Nova.
    • Na nova janela em nome da variável coloque ANDROID_HOME, e no valor da variável coloque o caminho até a pasta android-sdk que você acabou de instalar, por exempo: C:\Android\android-sdk. Dê OK.
      Variável ANDROID_HOME
    • Voltando às variáveis de ambiente, selecione a variável path, e clique em editar. Na nova janela no campo valor da variável, vá até o final da string e acrescente ;%ANDROID_HOME%\tools;%ANDROID_HOME%\platform-tools.
    • Estamos quase lá, agora precisamos instalar os pacotes do android. Abra o arquivo SDK Manager.exe, localizado dentro da pasta android-sdk.
    • Por padrão o Tools/Android SDK Tools já está instalado. Se por algum motivo ele não estiver marcado como instalado, selecione-o. Selecione também Tools/Android SDK Platform-toolTools/SDK build-tools (uma versão acima da 22), e na API selecione a mesma versão que você selecionou no Build Tools. Marque também Extras/Google USB Driver (necessário para debug direto no dispositivo), e clique em instalar.androi-sdk-manager-panel
    • Ao final das instalações nosso ambiente está configurado.
  6. Vamos fazer o teste. Voltando ao nosso aplicativo, abra o diretório do aplicativo pelo terminal e adicione a plataforma android.
    • Execute
      ionic platform add android

      ionic-add-platform-android

  7. Vamos dar o build no nosso .apk. Execute
    ionic build android

    build-androi-ionic

    • Após finalizado o processo, o caminho do .apk gerado é exibido no terminal.
  8. Podemos também debugar o aplicativo direto no dispositivo. Plugue o dispositivo via cabo USB, certifique de ter habilitado o USB debugging, e execute
    ionic run android

    run-android

É isso aí, boa sorte e bom desenvolvimento.

Aplicativos híbridos com Ionic. Você também pode começar a desenvolver agora!

Palestra com apresentação de um case desenvolvido em Ionic ilustrando os benefícios e facilidades do framework, e fazendo a comparação com o desenvolvimento nativo. Na segunda parte o que você precisa e como dar o start em um projeto Ionic.

Links

A potencialização tipográfica com a expansão das Web Fonts e a contínua responsabilidade do designer de interface nesse contexto

A evolução da Web trouxe cada vez mais ferramentas e soluções para um elaborado desenvolvimento de Websites. Artifícios técnicos criados por desenvolvedores Web para a produção do layout, objetivando atingir o resultado tipográfico desejado, já passam a ser obsoletos devido à implementação de novos recursos. O principal deles, as Web Fonts – suporte nativo para a utilização de fontes externas –, amplia o uso de fontes tipográficas para além das já conhecidas Web Safe Fonts. As Web Fonts já se tornaram elemento primordial ao layout das novas gerações de Websites e dão ao designer de interface a livre escolha para uma seleção tipográfica adequada ao projeto, não deixando de lado a importante premissa de cumprir com os requisitos básicos, entre eles, leiturabilidade e legibilidade, tendo em mente as mais variadas plataformas de acesso e público-alvo. Essa responsabilidade requer que o designer de interface continue a aprimorar seus estudos tipográficos e domine seus recursos técnicos no ambiente digital. Este trabalho tem o foco na tipografia como elemento primordial à comunicação, seu contexto histórico e evolução pelo meio digital até o ambiente Web, analisando as novas melhorias técnicas e o impacto visual gerado para o usuário que utiliza as aplicações Web em seu dia a dia. Dialoga-se diretamente com o designer de interface, mostrando como sua escolha precisa ser apurada e seguida por preceitos já antes estudados e abrindo caminho para um novo uso da tipografia digital.

AGRADECIMENTOS

Quero agradecer a todas as pessoas que participaram direta ou indiretamente deste trabalho, dedicando um pouco de seu tempo, ajudando a torná-lo possível.

Em um mundo repleto de mensagens que ninguém pediu para receber, a tipografia precisa freqüentemente chamar a atenção para si própria antes de ser lida. Para que ela seja lida, precisa contudo abdicar da mesma atenção que despertou. A tipografia que tem algo a dizer aspira, portanto, a ser uma espécie de estátua transparente. (BRINGHURST, 2005, p.23).

1 INTRODUÇÃO

Desde seus primórdios, a Web se utiliza de uma das mais velhas formas de comunicação: 95% de toda sua informação é composta de linguagem escrita. Sendo assim, um designer de interface deve ter conhecimento e controle no elemento primordial do layout, a tipografia. (REICHENSTEIN, 2006b).

Web Font é um termo genérico usado para se fazer referência ao uso de fontes externas. Para estabelecer a ligação entre páginas Web e as Web Fonts, deve ser utilizada a regra “@font-face”, a qual retorna como forte candidata a aprovação pelo W3C (World Wide Web Consortium) para se tornar um padrão de desenvolvimento do CSS nível 3. Isso traz a liberdade buscada pelos designers de interfaces para a escolha de qualquer fonte tipográfica. Segundo dados do site HTTP ARCHIVE (2013), entre novembro de 2010 e novembro de 2013, a utilização das Web Fonts cresceu de 1% para 35%, indicando que sua aceitação, mesmo antes da aprovação mencionada, é sinal de que os desenvolvedores ansiavam por uma solução eficaz e efetiva para o uso de texto na Web.

O novo recurso traz não só facilidade para os desenvolvedores, mas também melhorias técnicas e visuais: compressão otimizada, melhor desempenho, indexação, tradução, renderização, alto DPI (dots per inch – termo em inglês utilizado para medir a quantidade de pontos existentes em uma polegada na superfície onde uma imagem é exibida), entre outras. (GRIGORIK, 2012). Entretanto, a novidade traz consigo novas questões. Toda essa melhoria pode não ser de grande valor se: (a) o usuário tem a leitura dificultada em textos onde a família tipográfica escolhida é projetada para monitores de grande resolução, e não para dispositivos móveis de tamanhos reduzidos; (b) o tamanho da fonte utilizada é pequeno demais; (c) as entrelinhas estão reduzidas e o espaçamento é muito curto, etc.

Para usufruir das melhorias e solucionar os problemas citados, o designer de interface deve dominar a tipografia, seus conceitos e suas características relacionadas ao meio para o qual foi projetada. Seus projetos passam a contar com mais recursos para inovações, contudo não deixam de lado a necessidade de uma harmoniosa utilização tipográfica, boa leiturabilidade (facilidade com que o olho percorre o texto absorvendo a informação) e legibilidade (facilidade de distinção de um caractere do outro), entregando uma melhor experiência ao usuário.

O novo cenário é de melhorias, em que designers devem manter seu contínuo aprimoramento e estreitar ainda mais sua relação com desenvolvedores, responsáveis pela implantação de tais recursos, tornando-se grandes aliados no desenvolvimento de interfaces para uma melhor aplicação e utilização tipográfica.

Este trabalho tem como objetivo ajudar designers em seu aprimoramento e apresentar o mundo tipográfico aos desenvolvedores. O texto apresenta-se dividido em quatro partes: a primeira é uma breve explicação dos termos mais utilizados; a segunda, um compêndio bibliográfico a respeito da história da tipografia, apresentando seu percurso até a Web; a terceira explora esses novos recursos e possibilidades proporcionados pelas Web Fonts; a última propõe ao designer uma reflexão de sua responsabilidade para um uso tipográfico adequado e sua relação com as tecnologias recentes.

2 TERMINOLOGIAS

2.1 WEB

A Internet é uma rede global de redes de computadores, permitindo que milhares de computadores se comuniquem entre si quando conectados através dela, usando o protocolo TCP/IP. (FERREIRA, 2011).

A World Wide Web (WWW), ou simplesmente Web, é a rede que conecta documentos de hipertexto criados seguindo as sintaxes padrões, sendo HTML para estruturação de conteúdo e CSS para controle da exibição dos documentos HTML. A transferência pela rede é feita por meio do protocolo HTTP, e cada documento é identificado por um endereço único chamado URL. Utiliza-se um software chamado navegador/browser para acesso, exibição e interação com documentos na Web. (FERREIRA, 2011).

2.2 TIPOGRAFIA

A origem etimológica do termo tipografia remete à imprensa com tipos móveis, originada na Europa do século XV. Atualmente possui um amplo sentido, compreendendo manifestações de caráter experimental, fotoletras, cartazes, fontes digitais, etc, desvinculando-se assim dos tipos móveis de metal. Priscila Farias (2013) define tipografia como:

[…] o conjunto de práticas subjacentes à criação e à utilização de símbolos visíveis relacionados aos caracteres ortográficos (letras) e paraortográficos (tais como números e sinais de pontuação), para fins de reprodução, independentemente do modo como foram criados (a mão livre, por meios mecânicos) ou reproduzidos (impressos em papel, gravados em documento digital). (Priscila Farias, 2013, p. 18).

Com a evolução dos estudos de design gráfico, a tipografia se torna um dos focos de estudo e passa a ser uma das vertentes da área, dando origem assim ao termo design tipográfico, para diferenciar trabalhos nos quais a tipografia é o elemento mais importante. Devido à ligação com o passado, alguns termos oriundos da tipografia móvel ainda fazem parte da terminologia tipográfica, como “fonte tipográfica”, derivado do latim fundere (fundir). Refere-se a um dos estilos pertencentes a uma família de caracteres tipográficos, tendo como sinônimo “família tipográfica”. (FARIAS, 2013).

No meio digital, fontes digitais ou fontes de computador são arquivos digitais compostos por um set de caracteres (cada uma das letras, números e sinais que compõem uma fonte tipográfica) e glifos (forma particular dada a cada caractere, em que um caractere pode ter mais de um glifo) para renderização de texto. (MANIAN, 2009).

No ambiente Web, um novo termo tipográfico ganha forma: Web Font, um termo genérico para se fazer referência ao uso de fontes externas, em páginas HTML formatadas com CSS por meio do recurso “@font-face”. (FERREIRA, 2011).

3 CONTEXTO E HISTÓRIA TIPOGRÁFICA

3.1 PRIMÓRDIOS DA TIPOGRAFIA COM A COMPOSIÇÃO MANUAL

Como já apontava Claudio Rocha (2005), o progresso cultural da humanidade ocorre em ciclos, nos eixos de poder e de conhecimento, e se refletem diretamente na tipografia. Desde o início, esta impulsionou e foi impulsionada por questões técnicas, haja vista que estabeleceu relações intrínsecas com aspectos estéticos e econômicos. Isso pode ser verificado desde o surgimento dos tipos móveis de metal.

A escrita difundiu-se pelo mundo, multiplicando-se em diversos alfabetos e adaptando-se a novos ambientes. O maior impulsionador para essa disseminação foi a impressão com tipos móveis. Creditada a Johannes Gutenberg, a invenção dos tipos móveis data do início do século XV na Alemanha. (ROCHA, 2005). Antes empregados na China sem sucesso, devido à grande quantidade de caracteres do sistema de escrita chinês, os tipos móveis se adequaram bem ao alfabeto latino, visto que, neste, a quantidade de caracteres é reduzida a poucas letras que traduzem os sons da fala, sendo assim mais bem adaptados à mecanização. (LUPTON, 2006).

O processo de composição manual foi o único até o final do século XIX. Utilizava tipos fundidos de metal a partir de uma matriz, com a imagem do caractere em baixo-relevo, que por sua vez era formada por outra matriz em alto-relevo, chamada punção (Figura 1). Os tipos móveis em alto-relevo e invertidos eram organizados em um bastão componedor (Figura 2), formando linhas de texto com largura pré-ajustada. Estas últimas, por sua vez, eram dispostas em uma bandeja chamada Bolandeira (Figura 2), e a partir daí eram enviadas à prensa tipográfica para a impressão. Depois de impressos, os tipos eram reordenados em uma gaveta para uso posterior. (ROCHA, 2005).

Figura 1 – Punção, Matriz e Tipo Móvel

Fotografia de uma Punção, Matriz e Tipo Móvel
Fonte: ROCHA, 2005, p. 15

Figura 2 – Componedor e bolandeira

Fotografia Componedor e Bolandeira
Componedor à frente e bolandeira em segundo plano. Fonte: ROCHA, 2005, p. 16

Em 1884 o alemão Otmar Mergenthaler produziu um sistema mecânico chamado “Linotipo”, que fazia a composição e a fundição dos tipos. Equipado com um teclado, um magazine com as matrizes do tipo e uma fundidora acoplada, seu funcionamento se assemelhava ao de uma máquina de escrever: ao pressionar uma tecla, era liberada uma matriz do caractere correspondente, e assim sucessivamente até completar uma linha. Essa linha seguia mecanicamente para a fundidora, que fundia e ejetava cada linha por vez. Já as matrizes voltavam para o magazine e eram redistribuídas nos seus respectivos escaninhos. Esse tipo de composição aumentou a produtividade até seis vezes. (ROCHA, 2005).

3.2 A COMPOSIÇÃO A FRIO

No ano de 1947, a tipografia deixou o processo mecânico de lado e foi adaptada para o processo fotográfico, incrivelmente mais rápido. Em base, o sistema de fotocomposição era formado pela matriz dos caracteres em negativo, processados fotograficamente em suportes sensíveis à luz. No entanto, esse sistema possuía uma grande limitação: a ampliação dos caracteres. A partir daí, começaram a surgir as fotoletras e as letras transferíveis, chamadas de “Letraset”. (ROCHA, 2005).

3.3 A REVOLUÇÃO DIGITAL

Com o surgimento dos primeiros computadores, a tipografia foi automaticamente assimilada pelo meio. Os tipos deixaram o suporte físico e passaram a ser códigos binários. Uma fonte tipográfica virou um arquivo digital codificado com as descrições para sua visualização em tela (superfície responsável pela projeção das imagens do meio digital) e para saída de impressão. Essas codificações são interpretadas diretamente pelo sistema operacional. (ROCHA, 2005).

Essa revolução digital rompeu barreiras e se expandiu de forma rápida. O tipógrafo, que antes era responsável por todo o processo de impressão e de criação de tipos móveis, se especializou, dominando novas tecnologias para a criação de fontes digitais. A tipografia digital melhorou surpreendentemente a qualidade da tipografia impressa, devido aos ajustes mais precisos.

3.4 MIGRAÇÃO PARA O AMBIENTE WEB

3.4.1 Início da tipografia na Web

Com a Web, mais uma vez a tipografia alcançou novos patamares, expandindo-se consideravelmente. Devido à facilidade para se produzir uma fonte digital, a quantidade de fontes se multiplicou de forma rápida. No ano de 1993, a Web foi impulsionada com o surgimento do primeiro navegador gráfico, o NCSA Mosaic (Figura 3), capaz de exibir imagens e texto na mesma tela. Para os designers, surgiu então um novo desafio: a criação de layouts para esse novo ambiente. Entretanto, essa nova leva de navegadores possuía a limitação de dar suporte a uma única família tipográfica por padrão, necessariamente instalada no sistema operacional. (VEEN, 2011).

Nessa época o HTML não possuía nenhuma especificação para o controle das fontes e seus estilos, sendo estes controlados diretamente pelos navegadores. Foi somente em 1995 que a Netscape introduziu a tag “<font>”, padronizada somente na versão 2 do HTML. Essa tag especificava uma fonte a ser usada na renderização do texto, que deveria ser instalada previamente no computador do usuário.

O uso da HTML não dá aos designers de sites um ambiente para a manipulação direta bidimensional. Em lugar disto, fazer o design de um site da Web é como trabalhar com algo disforme. Logo que passamos a outra pessoa, adota uma outra configuração. (SIEGEL, 1999, p. 65).

Figura 3 – Interface do NCSA Mosaic 1.0

Printscreen da interface do NCSA Mosaic 1.0
Fonte: VEEN, 2011 apud NCSA/University of Illinois

Siegel (1999) já mostrava insatisfação com tais limitações tipográficas e assim levantava a questão do grande desafio de se desenvolver um site com uma boa tipografia, deixando claro que um bom resultado tipográfico era quase impossível. Ele também mostrava a necessidade de se recorrer a adaptações e truques para produzir páginas bonitas. Posteriormente a tag “<font>” foi descontinuada nas especificações HTML, promovendo a separação do conteúdo HTML e a estilização com o CSS. (FERREIRA, 2011).

A primeira especificação CCS, lançada em 1996, removeu definitivamente tags antes exclusivas para estilização do HTML. Sendo assim, o que antes era tratado pela tag “<font>” passou a fazer parte do CSS e recebeu as seguintes propriedades: “font-family” (família tipográfica), “font-style” (estilo itálico ou normal), “font-variant” (aplica versalete no texto),” font-weight” (peso) e “font-size” (tamanho). (SIEGEL, 1999).

3.4.2 Fallback Fonts e família de fontes genéricas

Com o atributo “font-family” do CSS, é permitido o uso de múltiplas fontes. Essas fontes são listadas, por exemplo, da seguinte forma:

font-family: Helvetica, “Lucida Sans”, Arial;

A primeira é a principal. Se o usuário não a possui em sua máquina, automaticamente o navegador buscará a próxima da lista, e assim sucessivamente. Essa fonte – escolhida como substituição – é chamada Fallback Font. Caso nenhuma dessas seja encontrada, o navegador exibirá o texto com sua fonte padrão. O mesmo processo ocorre quando o navegador encontra um caractere que não é suportado no set de caracteres da fonte atual.

Contudo, não se tinha garantia de que as fontes desejadas estariam instaladas no sistema operacional do usuário, portanto, havia o risco de que o site projetado para ser exibido em “Arial” viesse a ser exibido em “Times” (fontes de desenhos completamente diferentes, uma serifada e a outra sem serifa). Para amenizar um pouco o problema, o CSS permitiu a utilização de uma família tipográfica genérica, declarada após todas as Fallback Fonts. Exemplo:

font-family: Helvetica, “Lucida Sans”, Arial, sans-serif;

Tais famílias são divididas segundo as características visuais de cada uma delas. São elas:

  • Sans-serif – Fontes que não possuem serifas nem decoração;
  • Serif – Fontes que apresentam serifas;
  • Monospace – Fontes em que todos os caracteres possuem a mesma largura, independentemente de possuírem serifa ou não;
  • Cursive – Fontes que copiam a escrita cursiva;
  • Fantasy – Fontes que possuem símbolos, ícones ou caracteres decorativos.

3.4.3 Web Safe Fonts

Ao longo do tempo, os navegadores passaram do suporte a uma única fonte para uma quantidade de dezoito em 2008. Como não era possível garantir que o usuário possuiria determinada fonte, os fabricantes dos sistemas operacionais intervieram com o propósito de facilitar o desenvolvimento de Websites, criando as Web Safe Fonts (Figura 4). A Microsoft lançou o projeto Core fonts for the Web, iniciado em 1996 e finalizado em 2002 (MICROSOFT, 2002). O projeto consistia em um pacote de fontes padrões para Web, distribuído livremente, com algumas limitações de uso, atingindo um alto número de usuários. Desde então fontes como “Arial”, “Georgia” e “Verdana” se tornaram padrões para a Web.

Por virem pré-instaladas nas versões de sistemas operacionais após lançado esse pacote, as Web Safe Fonts puderam ser usadas com segurança, sendo referenciadas pela propriedade “font-family” do CSS. Comparada à quantidade de fontes em uso para a impressão, esta ainda era uma barreira a ser vencida pela tipografia na Web. (VEEN, 2011).

Figura 4 – Set das Web Safe Fonts

Exemplos das Web Safe Fonts
Fontes comuns e equivalentes nas versões de Windows e Mac. Fonte: AMPSOFT, 2008

3.4.4 Soluções alternativas: texto como imagem, object ou script

Devido à busca dos designers por conseguir usar fontes de sua escolha em Websites, várias soluções foram sendo implementadas. Até mesmo programadores buscavam soluções alternativas para utilizar fontes diretamente nos navegadores. Essas buscas impulsionaram a evolução da tipografia pela Web. Entre todas as tentativas, três soluções foram largamente usadas. São elas:

Uso de texto como imagem – Uma solução simples e mais praticada, consiste na substituição do texto HTML por uma imagem contendo o mesmo texto, porém utilizando-se uma fonte não Web Safe. O aspecto positivo é que essa solução possibilita o uso de qualquer fonte em um Website. Os aspectos negativos, por outro lado, são o fato de que ela impede a seleção do texto, aumenta o uso da banda, é ruim para serviços de otimização de pesquisas, não é traduzível, gera uma degradação da imagem em alta resolução e torna-se inacessível para quem usa dispositivos de assistência. Posteriormente técnicas de CSS aprimoraram seu uso, aplicando a imagem em cima do texto HTML da página. Isso elimina os problemas de acessibilidade e torna o texto pesquisável. (VEEN, 2011).

Texto embutido como object (Flash) – Muito comum também era o uso da ferramenta Flash. A solução é semelhante ao uso do texto como imagem, mas, dessa vez, utiliza-se um arquivo vetorial do software Flash como substituição, com a tag “<object>”. Esse arquivo era embutido no HTML e o texto era renderizado como vetor. Essa solução exibia melhor o texto e não tinha o problema da degradação sofrida pela imagem em alta resolução, além de permitir a seleção do texto. Seu uso, porém, requeria um plugin para exibição do arquivo instalado na máquina do cliente. Há ainda o fato da renúncia da empresa Apple em suportar o formato em seus dispositivos com plataforma iOS, fazendo com que usuários de iPads, iPods e iPhones não tenham acesso ao texto com esse recurso. (VEEN, 2011).

Renderização de texto por JavaScript – Outra solução implementada foi o uso de scripts na linguagem JavaScript, que substituem o texto por VML – Vector Markup Language (para Internet Explorer) ou SVG – Scalable Vector Graphics (para outros navegadores). Esses scripts automatizam a renderização do texto, porém ele não é selecionável ou redimensionável, e seu uso em grandes massas de texto pode implicar em um desempenho ruim. (VEEN, 2011).

Nenhuma das soluções apresentadas era suficientemente eficaz para a aplicação em blocos extensos de texto, funcionando melhor em frases curtas e em títulos. Ainda assim se tornaram cada vez mais comuns em um desenvolvimento Web, e essa demanda por utilização de fontes além das Web Safe Fonts trouxe a necessidade de uma padronização com solução mais adequada. (FERREIRA, 2011).

3.4.5 Web Fonts e o @font-face

Em 1998 foi liberada a especificação do CSS2. Ela tinha o objetivo de trazer melhorias para o uso da tipografia na Web e promovia um avanço até então mal explorado. As novas especificações acrescentaram a regra “@font-face”, que possibilitava o download de fonte externa para o Website, tornando possível o uso de fontes não pré-instaladas para a exibição das páginas. Tecnicamente, a regra faz apenas a ligação para o arquivo da fonte, porém o navegador necessita fazer o download desse arquivo para exibição. Apesar da evolução que isso traria, essas novas técnicas não tiveram muito uso na época e foram removidas das especificações do CSS2.1. (MANIAN, 2009).

Greg Veen (2011) atribui à incansável batalha entre os navegadores na década de 90, ou seja, entre Internet Explorer e Netscape – com suas implementações inconsistentes –, um dos motivos pelo atraso no uso das Web Fonts. Somente uma década depois, com os rascunhos do CSS3, o interesse pelo uso de fontes externas retornou, e novamente a regra “@font-face” voltou a vigorar, trilhando assim o avanço tipográfico tão esperado.

Contrariando as especificações oficiais, desde sua versão 4.0, lançada em 1997, o navegador Internet Explorer possui suporte nativo ao “@font-face”. A Microsoft implementou um novo formato de fonte chamado EOT, existente até a versão 8 do navegador. Desde 2007, um por um, os maiores navegadores gráficos começaram a oferecer suporte à antiga regra (inclusive navegadores de dispositivos móveis) utilizando formatos diversificados – os já padrões de fontes para desktop TrueType e OpenType, além do SVG e do WOFF (Web Open Font Format – formato que une as tecnologias dos arquivos TrueType e OpenType, formato aceito como padrão para as Web Fonts) – e ignorando o formato EOT da Microsoft. (MANIAN, 2009).

A utilização de uma Web Font é simples, bastando somente fazer a ligação para o arquivo da fonte ao qual se pretende fazer uso. Em certos casos, o desenvolvedor pode preferir usar a fonte instalada localmente na máquina do usuário e somente fazer o download quando essas fontes não estiverem disponíveis. Isso é possível utilizando-se “local()” na definição do caminho do arquivo na regra “@font-face”. O navegador fica encarregado de fazer essa verificação e carregar somente uma fonte. (DAGGETT, 2009).

Veja o exemplo de uso a seguir:

    @font-face {
        font-family: Helvetica;
        src: local("Helvetica Neue"),
        url(MinhaHelvetica.ttf);
    }

Para Fink (2010), esse suporte era a peça indispensável que faltava na Web desde seu surgimento, dando forma assim a um cenário tipográfico emergente, ditando um novo caminho, com novas possibilidades.

4 A POTENCIALIZAÇÃO TIPOGRÁFICA COM O ADVENTO DAS WEB FONTS

4.1 RENDERIZAÇÃO DE UMA FONTE PELO MEIO DIGITAL

Um dos fatores importantes a favor do uso das Web Fonts é a melhor renderização em tela. Mas esse ainda é um fator dependente de tecnologias dos navegadores, dos sistemas operacionais e dos dispositivos, o que se torna um desafio na escolha de uma boa Web Font. Para compreendermos um pouco esse problema, é preciso entender como o meio digital renderiza a fonte.

Uma fonte digital é um arquivo em vetor que pode ser escalonado, sem perder a qualidade. Sua renderização em tela é baseada em grides de pixels, referentes à resolução dos monitores ou dispositivos em que serão exibidos. Essa renderização também sofre interferência dos sistemas operacionais e navegadores. Por isso uma fonte pode ser exibida de formas diversas em um mesmo navegador com sistemas diferentes, apresentando melhor leiturabilidade em um do que no outro. Na imagem seguinte (Figura 5), a letra “O” é representada em um grid de pixels, mostrando como essa renderização é feita em uma tela digital. No grid, os pixels podem aparecer como ligados (com cor) ou desligados (sem cor). Conforme o tamanho da fonte, o sistema operacional liga os pixels que melhor representam a exibição da forma. Porém, nem sempre o sistema faz isso da melhor maneira. Observando a imagem, vemos que a representação do lado direito é mais fiel ao desenho da letra “O”, mantendo a similaridade entre os dois lados do caractere. Isso só é possível devido às instruções de hinting, programadas pelo designer de tipos antes de gerar o arquivo da fonte. São essas instruções que garantem que o glifo mantenha as proporções adequadas, melhorando drasticamente a leiturabilidade de textos em tamanhos pequenos e navegadores desatualizados. (VEEN, 2011). O hinting vem sendo usado desde a década de 80, antes mesmo da Web, para melhorar a renderização em impressoras de baixa resolução. Para Nick Sherman (2013), o hinting é para as fontes o que o design responsivo é para os Websites.

Figura 5 – Grid de pixels representando a letra “O”

Grid de pixels representando a letra O
A letra “O” do lado esquerdo parece deformada, com lados assimétricos. Na do lado direito, é possível ver as instruções de hinting que forçam a similaridade dos lados do caractere. Fonte: AHRENS, 2010

O fato de a fonte se apresentar diferentemente em navegadores diferentes faz com que o designer de interface tenha que se preocupar no início do processo com a escolha da Web Font ideal. É preciso se atentar ao fato de que fontes para impressão nem sempre serão bem exibidas em tela, por não possuírem as instruções de hinting. (VEEN, 2011). O trabalho para desenvolvimento do hinting é difícil, tedioso, demorado e caro. Algumas ferramentas de automatização facilitam o trabalho, mas em corpos pequenos o mais indicado ainda é o trabalho manual. Sherman (2013) exprime a vontade dos desenvolvedores de que no futuro isso não seja mais uma preocupação, devido à evolução das telas e dos softwares de renderização.

A ideia de “modificação” dos caracteres em diferentes situações não é nova. Gutenberg já usava compensações óticas em diferentes tamanhos de texto (Figura 6), alterando espaçamento, proporções, largura e outros detalhes para otimização da impressão. Seguindo esse conceito, já se veem casos dos desenvolvedores detectarem as condições de uso e oferecerem uma fonte específica para o contexto. Mais uma grande possibilidade para o uso da tipografia na Web. (SHERMAN, 2013).

Figura 6 – Comparação dos tamanhos da letra “a”

Vários tamanhos da letra “a” da fonte Century Expanded em tipos móveis, que possuíam variações que compensavam problemas técnicos de impressão, para uma melhor leiturabilidade mantendo suas características. Fonte: SHERMAN, 2013

Na renderização é necessário outro recurso além do hinting. Cabe ao anti-aliasing a suavização das curvas (Figura 7), processo que consiste basicamente em adicionar pixels semi-transparentes nas bordas dos caracteres, evitando o serrilhado. A eficiência do anti-aliasing depende do hinting e também dos softwares e sistemas operacionais e juntos são de extrema importância para tornar o texto legível. (GIANNATTASIO, 2009).

Figura 7 – Comparação anti-aliasing

Fonte “Goudy Oldstyle Bold” em corpo 42pt, com e sem aplicação do anti-aliasing. Fonte: GIANNATTASIO, 2009

Anteriormente não existia nenhum controle de como a fonte seria renderizada na Web para o usuário. Com os estudos do CCS3, duas novas possibilidades dão certo controle na entrega do texto em HTML: o já citado “@font-face” e a nova propriedade “font-smooth”.

Tom Giannattasio (2009) defende que, com o “@font-face”, podemos criar um mundo visualmente mais atraente da tipografia na Web, eliminando o uso de fontes locais de baixa qualidade ou fontes feitas para impressão, péssimas para visualização em tela – principalmente em pequenos textos –, e entregando fontes com melhor controle de hinting e mais legíveis. Já a propriedade “font-smooth”, ainda obscura no meio dos desenvolvedores, permite controlar quando a suavização é usada, mas não como, o que é feito pelo sistema do usuário. Ainda não é suportado completamente em todos os maiores navegadores; quando implementado, proverá a capacidade de desabilitar o anti-aliasing, uma boa solução em textos de tamanhos pequenos.

Veja um exemplo, com seus valores possíveis:

font-smooth: auto | never | always | <absolute-size> | length

Cada navegador depende do sistema operacional com sua tecnologia própria para a renderização da fonte. Infelizmente eles podem estar sujeitos a problemas de compatibilidade com os sistemas e renderizarem de forma problemática. Sobre esses aspectos, os designers de interface não possuem controle. Conforme Tom Giannattasio (2009), o ideal é entender as nuances de cada navegador e se adequar a cada plataforma.

4.2 SIMILARIDADES ESTILÍSTICAS ENTRE TEXTOS DE DIFERENTES IDIOMAS

Seguindo o caminho trilhado hoje pela Web, a tipografia digital vem há algum tempo seguindo padronizações. Por volta de 1987, começaram os estudos para que os computadores pudessem interpretar corretamente caracteres de qualquer tipo de escrita de forma consistente. (UNICODE, 2014).

Esse padrão já é comum em fontes digitais para desktop, e as Web Fonts também o seguem. Ele é tratado internamente pelos sistemas operacionais, porém deve ser corretamente implementado pelos designers de tipos na montagem do arquivo de fonte.

O uso das Web Fonts dá ao designer de interface a possibilidade de manter a similaridade visual de textos com idiomas diferentes, principalmente os não latinos como árabe e japonês, entre outros. Línguas menores e escritas antigas também sofrem com a falta de fontes com suporte adequado. (DAGGETT, 2009). A imagem a seguir (Figura 8) mostra a mesma família tipográfica com características similares nos caracteres de alfabetos como o grego e o cirílico, mantendo proporções de largura e altura em cada uma.

Figura 8 – Fonte Ubuntu

Fonte: MAAG, 2014

O uso de uma Web Font não é necessário somente para suporte de determinado idioma. Muitas vezes é preciso usar pesos ou estilos diferentes no texto (Figura 9), aplicando um negrito ou um itálico, e nem sempre famílias tipográficas possuem mais de um peso. (DAGGETT, 2009).

Figura 9 – Família da fonte M+

Fontes japonesas do projeto livre M+ com vários pesos. Fonte: DAGGETT, 2009

A respeito desse uso de negritos e itálicos, uma nova funcionalidade é aguardada. Quando se declara que o texto será negrito ou itálico, e a família da fonte não possui esse peso ou estilo, o navegador irá forçar de alguma forma criando os pesos desejados, resultando assim em uma distorção da tipografia, o que pode ocasionar resultados ruins. Devido a cada implementação de navegador, a renderização de um negrito pode ser mais forte em um e suave em outro. Para controlar essa situação, o CSS3 possui a propriedade “font-synthesis”, que controla se essa distorção pode ou não ser feita pelo navegador. (STEARNS, 2012).

Na figura 10, a fonte “Lora” primeiramente é forçada a ser renderizada em negrito e itálico com as tags “<strong>” e “<cite>” respectivamente. O resultado não é tão ruim, porém o negrito não possui um bom contraste com o resto do texto, e o itálico parece um pouco inclinado demais. Na segunda frase, negrito e itálico são parte da família tipográfica, muito mais condizentes visualmente com o texto.

Figura 10 – Comparação de negrito e itálico reais x forçados

Fonte: STEARNS, 2012

4.3 OPENTYPE E SEUS RECURSOS

OpenType é o mais recente e moderno formato de arquivo para fontes digitais. Seus benefícios vão desde a compatibilidade entre plataformas ao suporte abrangente ao set de caracteres baseado no padrão Unicode. Com o OpenType, é possível incluir caracteres de muitas línguas em uma única fonte, suportando mais de 65 mil glifos e simplificando o processamento de texto multi-lingue. Conta-se também com recursos que propiciam um rico suporte linguístico e controle tipográfico avançado. (FONTSHOP INTERNATIONAL, 2012).

Um simples arquivo de fonte pode conter vários glifos não-padrões, como os algarismos de estilo antigo, algarismos tabulares, versaletes, frações, caracteres caudais, superiores e inferiores, letras titulares, alternativas estilísticas e contextuais, uma ampla gama de ligaturas, símbolos e ornamentos. Os recursos OpenType permitem automatizar posicionamento ou substituição de glifos. (FONTSHOP INTERNATIONAL, 2012, tradução nossa) 1

Com a capacidade dos navegadores de exibirem fontes OpenType, alguns também já começam a dar suporte aos recursos presentes no formato. Esse controle será via CSS e junto com a regra “@font-face”, aguardando sua publicação pelo W3C (WORLD WIDE WEB CONSORTIUM, 2014).

Alguns desses recursos são:

Versaletes – Substituem as letras em caixa-baixa por letras em caixa-alta mantendo a altura das de caixa-baixa.

Figura 11 – Exemplo de versaletes

Versaletes originais da fonte “Arno Pro” na segunda frase. Fonte: HERRMANN, 2010

Set de figuras – O set de figuras compreende os algarismos alinhados (algarismos que seguem as mesmas linhas de base e altura) e os algarismos de estilo antigo (algarismos que possuem descendentes e ascendentes, mais bem utilizados no texto corrido) (Figura 12), seguindo a proporção tabular (algarismos que possuem a mesma largura) ou proporcional (Figura 13). (HERRMANN, 2010).

Figura 12 – Exemplo de algarismos de estilo antigo

Na frase em azul, é aplicado os algarismos de estilo antigo; os algarismos 3 e 6 possuem descendentes e ascendentes, respectivamente. Fonte: HERRMANN, 2010

Figura 13 – Set de figuras

Fonte: Adaptado de HERRMANN, 2010

Ligaturas – Junção de letras (Figura 14), que podem ter um propósito estilístico ou histórico. (HERRMANN, 2010).

Figura 14 – Exemplo de ligaturas

Fonte: HERRMANN, 2010

Alternativas contextuais – As ligaturas são opcionais, porém, em alguns casos, dependendo da fonte (Figura 15) ou língua, é necessário que o caractere seja substituído de acordo com sua posição ou caractere seguinte. (HERRMAN, 2010).

Figura 15 – Exemplos de alternativas contextuais

Fonte: HERRMANN, 2010

Línguas como o árabe requerem essa substituição para sua escrita, processo em que o caractere é completamente afetado pelos caracteres ao redor (Figura 16). (DAGGETT, 2009).

Figura 16 – Exemplo de escrita a árabe

Fonte: DAGGETT, 2009

Frações – Um set de caracteres básico em toda fonte possui as frações 1⁄4, 1⁄2 e 3⁄4. Com o OpenType porém é possível a criação de quantas frações forem necessárias (Figura 17). (HERRMANN, 2010).

Figura 17 – Exemplo de frações

Fonte: HERRMANN, 2010

Kerning – Ajuste de espaçamento em pares de letras específicos (Figura 18), em parte, uma letra avança sobre o espaço de outra.

Figura 18 – Exemplo de Kerning

Fonte: Adaptado de STEIN, 2014

4.4 FONTES DE SÍMBOLOS, ÍCONES E MULTICOLORIDAS

A busca por um melhor desempenho é um processo contínuo. A Web passou por diversas formas de construção de sites, e cada uma delas buscava uma padronização mais eficiente. Entre esses processos, temos o uso de sprites de imagens (Figura 19), cujo conceito é simples. Basicamente o que ele faz é juntar várias imagens pequenas e ícones dentro de uma única imagem, reduzindo assim o número de requisições DNS, melhorando o desempenho e a experiência do usuário. (SUDA, 2013).

Figura 19 – Sprite de imagens do site Google.com

Fonte: [SPRITE DE IMAGENS DO GOOGLE], 2014

Esse conceito de sprite de imagens é transportado para as Web Fonts. Já existem Web Fonts específicas (Figura 20) com símbolos, ícones e decorações, e esse número não para de aumentar. Elas possuem os mesmos benefícios – tamanho de arquivo reduzido e diminuição de requisições, usufruindo também do poder de renderização em alta resolução – e substituem várias imagens do site com um simples arquivo de fonte. (SUDA, 2013).

Figura 20 – Fonte Glyphicons

Alguns dos ícones disponíveis na fonte Glyphicons. Fonte: GLYPHICONS, 2014

Pensando em acessibilidade, o uso de Web Fonts para símbolos tem que ser planejado e cuidadoso. Algumas fontes mapeiam os símbolos como letras; por exemplo, quando digitado um “E” será renderizada a figura de um envelope no navegador. Problemas poderão acontecer quando o envio da fonte falhar (Figuras 21 e 22), vindo a gerar caracteres em lugares aleatórios, que não farão sentido algum. Portanto é necessário o auxílio do CSS para contornar esses problemas. Uma das saídas dada por Brian Suda (2013) é o uso correto do texto direto no HTML e a inserção do símbolo pelos pseudo-elementos do CSS “:before” ou “:after”. Assim, se você quiser usar um ícone para um link que leva para uma outra página, o texto do link será “próxima página” escondido, e o ícone de uma seta será exibido via CSS. O autor aponta que esses problemas poderiam ser mais bem resolvidos se as fontes seguissem os padrões corretos do Unicode para esses símbolos. Esses caracteres especiais Unicode não são conectados semanticamente com nenhuma letra do alfabeto. E se a fonte não for carregada, será exibido somente um Box vazio substituindo o caractere ao invés de uma letra.

Figura 21 – Página do site @CRAIGMOD

Carregamento completo do site com Web Font Fonte: LYNAM; MOD, 2009

Figura 22 – Página do site @CRAIGMOD

Carregamento incompleto com falha no download da Web Font Fonte: LYNAM; MOD, 2009

Ampliando ainda mais o uso dos ícones e símbolos em Web Fonts, Suda (2013) recorre ao uso das ligaturas OpenType, incentivando a ideia de que se pode fazer o uso de substituições da seguinte forma. Ao usar um texto com o seguinte dizer “A List Apart”, ele será convertido completamente para um único símbolo representando o logotipo do site A List Apart.

Apesar das vantagens de se usar uma fonte com ícones ou símbolos, elas possuem uma barreira ainda em estudo: as fontes somente aceitam uma única cor. Até é possível o uso de degradês, com algumas técnicas CSS para emular duas cores, mas, se necessário o uso de múltiplas cores, atualmente é preciso retornar ao uso dos sprites de imagens. Em vista de resolver essa situação, as empresas de sistemas operacionais começaram a propor soluções com fontes multicoloridas, por exemplo a Apple, que trouxe a fonte Apple Color Emoji (Figura 23). (SUDA, 2013).

Figura 23 – Fonte Apple Color Emoji

Fonte: HERRMANN, 2013

A solução proposta pela Apple e também pela Google utiliza um arquivo PNG para gerar o caractere e, com isso, consegue usar múltiplas cores. Já o Windows vem com uma proposta diferente (Figura 24), introduzindo o suporte de vetores em camada, sendo que cada camada recebe uma cor (Figura 25). (HERRMANN, 2013).

Figura 24 – Fonte Segoe UI Emoji

Fonte: HERRMANN, 2013

Figura 25 – Esquema de cores em camadas

Fonte: HERRMANN, 2013

Certamente as fontes de ícones e símbolos estão sendo fortemente impulsionadas e padronizadas com a expansão das Web Fonts devido à grande aceitação, sendo agora as fontes multicoloridas um novo avanço tipográfico que, embora já existente, ainda se encontra em estado de estudo, aguardando uma boa aceitação e padronização. Conforme Siegel (1999), os designers deveriam concentrar-se nas coisas que eles podem influenciar e esperar futuramente por melhores padrões, sendo as fontes multicoloridas apenas um exemplo de tecnologia a que esses profissionais devem se atentar. Sendo assim, designers precisam se manter atentos às tecnologias, a fim de poderem continuar impulsionando ainda mais o campo tipográfico e aprimorando seus conhecimentos.

5 A CONTÍNUA RESPONSABILIDADE DO DESIGNER DE INTERFACE NO CONTEXTO DAS WEB FONTS

Antes da implementação da regra “@font-face”, o uso de fontes externas era limitado, sem uma solução técnica amplamente implementada. Agora, com o uso dessa nova regra, juntamente com a expansão das Web Fonts, designers foram instigados a avaliar suas possibilidades, em um cenário de convergência entre as nuances da tipografia impressa e a natureza dinâmica da Web. (LYNAM; MOD, 2009). Sendo assim, resta aos designers buscarem conhecer esses novos avanços e atualizações, ainda mais num ambiente tão dinâmico como o da Web, o qual passa por modificações constantes, sempre procurando obter melhores padronizações e recursos que compreendam as necessidades de desenvolvedores e designers.

A chegada das Web Fonts promete abolir toda a monotonia tipográfica, antes dominada pelas Web Safe Fonts, dando ao designer a possibilidade de selecionar qualquer fonte para seu layout. (HERRMANN, 2011). Porém, tal liberdade requer cuidado na seleção e precisa ser analisada minuciosamente. Um dos requisitos mais ignorados para uma seleção adequada ao projeto são os fatores histórico-culturais conectados ao tipo da fonte. Muitos estilos estão atrelados a períodos históricos, e é preciso saber em que momento essas fontes foram desenvolvidas, buscando conhecer o propósito para o qual foram feitas. Às vezes a fonte parece ser visualmente adequada, mas pode gerar uma má interpretação. Por exemplo, fontes góticas (Figura 26) são mais pesadas, escuras e afiadas, sendo mais adequadas quando se quer transmitir uma ideia de medo ou escuridão (Figura 27). Esse conhecimento usado de forma inteligente potencializa uma boa escolha e traz maior clareza ao usuário. (MARIA, 2009).

Figura 26 – Exemplo de fonte gótica

Fonte: REYNOLDS, 2010

Figura 27 – Exemplo de arquitetura gótica

Fonte: SIVYER, 2011

Siegel (1999) afirmava que “…uma boa tipografia deve procurar facilitar as coisas para o leitor, não desafiá-lo”. O autor exprime a ideia que a tipografia seja boa. Mas um bom uso tipográfico não depende somente de uma boa fonte, e sim de uma boa escolha. Para isso, o designer deve compreender o projeto como um todo, suas características, objetivos, suporte, aplicação, público-alvo, aspectos culturais e necessidades especiais. Uma boa seleção leva em conta a legibilidade, sendo que algumas fontes são mais legíveis em tela do que outras, e essa legibilidade é em parte influenciada pela altura-de-x (altura das letras minúsculas) e a altura total da fonte (LYNCH; HORTON. 2008), que por sua vez também sofrem influência direta dos recursos de renderização já mencionados anteriormente.

Após tais conceitos terem sido compreendidos e levados em consideração, e uma fonte ou família tipográfica adequada ter sido selecionada para o projeto, o designer passa a contar com os recursos OpenType avançados para a otimização tipográfica. Tais recursos propiciam ajustes mais apurados, com uma ampla gama de substituições automáticas e ajustes de espaçamento específicos para pares de letras. E por mais atuais que esses novos recursos possam parecer, é importante ressaltar que, no âmbito tipográfico, muitos deles já existiam e vêm sendo aprimorados desde os tipos móveis, sendo adaptados para o meio em que a tipografia se espalhou. Recursos como kerning, versaletes, letras caudais, ligaturas (Figura 28 e 29), etc, existentes já na tipografia digital, somente agora podem ser usados nativamente na Web sem nenhum recurso adicional. Portanto é responsabilidade do designer saber e utilizar regras que remontam do início da tipografia até hoje (BOULTON, 2005), regras estas extremamente úteis e aplicáveis no ambiente Web. Conforme Reichenstein (1996a), a tipografia é uma disciplina antiga que requer muito estudo e esforço repetitivo, e na prática ela não se resume a escolher ou criar fontes, mas se relaciona ao objetivo de modelar o texto para uma experiência de leitura ideal.

Figura 28 – Exemplo de ligatura “ft” da fonte “Garamond” em tipo móvel.

Fonte: ULLRICH, 2006

Figura 29 – Exemplo de ligatura “ft” da fonte “Garamond” digital.

Fonte: MICO, 2013

Otimizar a tipografia é melhorar leiturabilidade, acessibilidade e usabilidade. Sua organização em blocos de texto e junção com imagens é o que os profissionais vêm aprimorando desde os primórdios tipográficos, portanto não devem ser negligenciados. Qualquer designer pode usar uma boa tipografia, porém bons profissionais tratam o texto como parte importante da interface, certificando-se de uma boa leitura na maioria dos navegadores e plataformas, do uso correto de entrelinhas, do espaçamento entre letras, do espaço de respiro e de um bom contraste, para ajudar em uma boa leiturabilidade. Somente ter o trabalho de escolha de fonte para um projeto não é o suficiente, mas um bom uso tipográfico pode, inclusive, ser feito somente com uma única família. (REICHENSTEIN, 2006b). O uso de uma boa tipografia garante unidade gráfica, e a seleção de uma família confere consistência. Executando corretamente tais requisitos, não será necessário ter a certeza de que um site será exibido igual em várias plataformas e dispositivos, mas é necessário apurar sua facilidade de uso e de leitura. (REICHENSTEIN, 2006a).

Dominando tais conhecimentos em relação aos atuais recursos por parte do designer, é obrigação do mesmo compartilhar tais conhecimentos com desenvolvedores, atualmente ainda os responsáveis pela codificação dos layouts, aplicando corretamente tais recursos. Porém, essa responsabilidade pode voltar a se concentrar futuramente somente no designer com a melhora de programas capazes de codificar o layout.

6 CONCLUSÃO

O uso da tipografia como o pilar da comunicação escrita passou por um longo caminho evolutivo até o meio digital. Neste último, sua utilização extrapolou tudo o que já havia sido feito, e inserida na Web (inicialmente com um suporte limitado, agora com a expansão das Web Fonts) trouxe consigo uma perspectiva de melhorias visuais com a liberação do uso de qualquer família tipográfica e com recursos que possibilitam controles avançados que influenciam em uma melhor leitura. Assim como vem ocorrendo na Web desde o início, o caminho para as Web Fonts se estabilizarem é o da padronização. Algumas discussões ainda vigoram, como a forma de sua aplicação e qual o formato será aceito pelo W3C. Com essa padronização, todos os navegadores terão que se adaptar, eliminando assim os atuais conflitos de formatos. Antes de uma padronização oficial, porém, o cenário é de uma expansão exponencial. O uso de Web Fonts já é feito por uma quantidade expressiva de sites, e já começamos a vê-las ampliando seu potencial, absorvendo os sprites de imagens com as fontes de símbolos e ícones. Essa prática já se espalha no desenvolvimento de sites e é bem aceita pela comunidade de desenvolvedores.

As Web Fonts trazem consigo funcionalidades antes já implementadas nas fontes digitais para desktop e impressão. Os recursos OpenType ampliam o controle tipográfico e fornecem possibilidades de uso até então pouco exploradas pelos desenvolvedores e designers de interface. Lembrando que nenhum desses recursos tecnológicos são novidades no mundo tipográfico, tendo os seus primódios nos tipos móveis. Sendo assim, atualmente, designers têm o papel de compartilhar com desenvolvedores o seu conhecimento tipográfico prévio, para que juntos possam chegar ao resultado objetivado na produção do layout. Com a possível expansão de programas que recortam o layout, gerando o código, designers terão uma ferramenta em que poderão trabalhar sem depender da interferência do desenvolvedor quanto à codificação do layout, porém tais programas precisam ter implementados esses novos recursos tipográficos.

Com a evolução dos monitores e telas display e com a tecnologia da tela de retina de alta resolução, logo não será mais necessário o tão meticuloso trabalho manual para controle do hinting, dando mais liberdade para o designer na escolha de uma fonte, trazendo melhorias na renderização e, consequentemente, na leiturabilidade.

Para o futuro, já vemos indícios de uma nova expansão tipográfica, tendo em vista as fontes multicoloridas, ainda muito limitadas para uso e sem um formato definido, em um cenário onde empresas brigam na criação de um formato que seja aceito por todos. Assim que surgirem ferramentas que possibilitem sua criação, designers poderão dar utilidades até então inexploradas.

Tendo em vista tanta atualização, os designers possuem a responsabilidade de continuarem seu aprimoramento, não deixando para trás seu conhecimento tipográfico prévio, para que, na criação de interfaces, usem a tipografia como uma aliada, integrando-a à interface, dando mais clareza na comunicação com usuário. Sua interface precisa atender aos atuais dispositivos e telas como Smart TVs, mas também estar preparada para novos dispositivos, como os SmartWatchs, e navegadores não tão explorados como os de consoles de Xbox, Playstation, etc.

REFERÊNCIAS

The typographic enhancements with the expansion of Web Fonts and the continuing responsibility of the interface designer in this context

The evolution of the Web has brought each time more tools and solutions for an elaborate development of Websites. Skillful technics created by Web developers to produce the layout, aiming to achieve the desired result typographic, are already being obsolete due to the implementation of new resources. The main one, Web Fonts – native support for the use of external sources – expands the use of typefaces in addition to the already known Web Safe Fonts. The Web Fonts have become a core component to the layout of the new generations of Websites and give the designer the choice interface for a proper design to typographic selection, leaving aside the important premise to meet the basic requirements, including, readability and readability, keeping in mind the various access platforms and target audience. This responsibility requires that the interface designer to continue to improve their typographic studies and master it is technical resources in the digital environment. This work is focused on typography as the primordial communication element, its historical context and evolution of the digital means to the Web environment, analyzing the new technical improvements and the visual impact generated for the user who uses the Web applications in their daily lives. It dialogue directly with the designer interface, showing how your choice needs to be refined and followed by precepts already studied before and making way for a new use of digital typography.

THANKS

I want to thank all the people who participated directly or indirectly of this work, devoting some of their time, helping to make it possible.

Em um mundo repleto de mensagens que ninguém pediu para receber, a tipografia precisa freqüentemente chamar a atenção para si própria antes de ser lida. Para que ela seja lida, precisa contudo abdicar da mesma atenção que despertou. A tipografia que tem algo a dizer aspira, portanto, a ser uma espécie de estátua transparente. (BRINGHURST, 2005, p.23).

1 INTRODUCTION

Since it’s beginnings, the Web has used one of the oldest forms of communication: 95% of all it’s information is made up of written language. Thus, an interface designer should have knowledge and control of the fundamental element of layout, the typography. (REICHENSTEIN, 2006b).

Web Font is a generic term used to make reference to the use of external fonts. To establish a connection between web pages and Web Fonts, it is necessary to use the rule “@font-face”, that returns as strong candidate to W3C (World Wide Web Consortium) approval, to be a CSS level 3 development standard. This allows Interface Designers to freely choose any typography font. According to data from the website HTTP ARCHIVE site (2013), between November 2010 and November 2013, Web Fonts usage increased from 1% to 35%, indicating that it’s acceptance, even before the mentioned approval, is a signal that developers were anxious for an efficient and effective solution for the use of text on the Web.

The new feature not just brings ease to developers, but also, technical and visual benefits: optimized compression, better performance, indexing, translation, rendering, high DPI (dots per inch – English term used to measure the dots quantity existing in a inch, on surface where the image is displayed), among other things. (GRIGORIK, 2012). However, that new feature brings with it new questions. This whole benefit can’t be valuable if: (a) the user has difficulties to read texts where the chosen typographic family is projected to high resolution monitors and not for low size mobile devices; (b) the font size used is too small; (c) the leadings are reduced and spacement is too short, etc.

To enjoy the benefits and solve all cited problems, the Interface Designer must dominate the typography, it’s concepts and features related to the way it was projected. Your projects now have more resources for innovations, however, they can’t leave aside the need for a harmonic typographic usage, good readability (ease where the eye crosses the text, absorving information) and legibility (ease of distinction of an character to another), delivering a better experience.

The new scenario is made of benefits, where designers shall keep your continuous improvement and make closer your relation with developers, responsible for implant the resources, making themselves big allied in interface development for a better application and typographic usage.

This work has as objective, help designers to improve themselves and introduce the typographic world to developers. The text introduces itself divided in four parts: first one is a brief explanation of the most used terms; second, a bibliographic compendium about the typography history, introducing it’s journey to the Web; the third explores these new resources and possibilities made possible by Web Fonts; the last proposes to the designer a reflection of it’s responsibility for an appropriate typography usage and it’s relation with the latest technologies.

2 TERMINOLOGIES

2.1 WEB

The Internet is a global network of computer networks, allowing thousands of computers to communicate with each other when connected through it, using the TCP/IP protocol. (FERREIRA, 2011).

The World Wide Web (WWW) or simply the Web, is the network that connects hypertext documents created following standard syntax, being HTML for the structure of content and CSS to control the appearance of HTML documents. The transfer through the network is made by means of the HTTP protocol, and each document is identified by a unique address called a URL. It uses a software called navigator/browser to access, view and interact with documents on the Web. (FERREIRA, 2011).

2.2 TYPOGRAPHY

The etymological origin of the term refers to the printing press with movable type, originated in the 15th century Europe. At present it has a broad meaning, including demonstrations of experimental character, photoletter, posters, digital fonts, etc, as well disentailing of metal movable type. Priscila Farias (2013) defines typography as:

[…] o conjunto de práticas subjacentes à criação e à utilização de símbolos visíveis relacionados aos caracteres ortográficos (letras) e paraortográficos (tais como números e sinais de pontuação), para fins de reprodução, independentemente do modo como foram criados (a mão livre, por meios mecânicos) ou reproduzidos (impressos em papel, gravados em documento digital). (Priscila Farias, 2013, p. 18).

With the evolution of the graphical design studies, the typography becomes one of the foci of study and passes being one of the sections of the area, resulting in the term typographical design, to differentiate works in which the typography is the most important element. Due to the link with the passed, some terms originating from mobile typography are still part of the typographical terminology, like “typographical font”, derived from the lating fundere (fund). It refers to one of the styles belonging to a family of typographical characters, having the synonym “typographical family”. (FARIAS, 2013).

In a digital environment, digital fonts or computer fonts are digital files composed by a set of characters (each one of letters, numbers and signs that compose a typographical font) and glyphs (a particular form given to each character, in that a character can have more than one glyph) for the rendering of text. (MANIAN, 2009).

In the web environment, a new typographical term gets the form: Web Font, a generic term to make a reference to the use of external fonts, in HTML pages formatted with CSS by meand of the resource “@font-face”. (FERREIRA, 2011).

3 CONTEXT AND TYPOGRAPHICAL HISTORY

3.1 THE ORIGINS OF TYPOGRAPHY WITH MANUAL COMPOSITION

As pointed out by Claudio Rocha (2005), the cultural progression of humanity occurs in cycles on the axes of power and knowledge, and this is directly reflected in typography. Since its beginning, it is and was driven by technical issues, as seen in the formation of close relationships with aspects of aesthetics and economics. This can be seen beginning with the appearance of the metal moving type.

Writing spread throughout the world, multiplying itself in diverse alphabets and adapting itself to new environments. The biggest driving force for this dissemination was printing with moving type. Credited to Johannes Gutenberg, the invention of moving type dates to the beginning of the 15th century in Germany. (ROCHA, 2005). Before that, it had been attempted without success in China, due to the large quantity of characters in written Chinese. Moving type adapted well to the Latin alphabet, as in this writing system: in this alphabet, the amount of characters is reduced to a few letters representing speech sounds, and are thus better suited to mechanization. (LUPTON, 2006).

The process of manual composition was the only one until the end of the 19th century. It used metal types cast from a matrix with the image of a character in low relief, which, in turn, was formed by another matrix in high relief called a punch (Figure 1). The reversed types in high relief were organized on a composing stick (Figure 2), forming lines of text with pre-adjusted widths. In turn, the latter were arranged on a tray called a type galley (Figure 2), and from there were sent to the printing press to be printed. After printing, the types were reordered in a drawer for later usage. (ROCHA, 2005).

Figure 1 – Punch, Matrix and Letterpress

Fotografia de uma Punção, Matriz e Tipo Móvel
Source: ROCHA, 2005, p. 15

Figure 2 – Composing stick and type galley

Fotografia Componedor e Bolandeira
Composing stick in front and type galley in the background Source: ROCHA, 2005, p. 16

In 1884, a German named Ottmar Mergenthaler produced a mechanical system called “Linotype” which cast and arranged the types. Equipped with a keyboard, a magazine with type matrices and a coupled smelter, its operation was likened to that of a typewriter: upon pressing a key, a matrix of the corresponding character was released, and so on until a line was completed. This line went mechanically to the smelter, which fused and ejected each line at a time. The matrixes were already returned to the magazine and redistributed in their respective compartments. This kind of composition increased productivity up to six times. (ROCHA, 2005).

3.2 Cold Typesetting

In 1947, typography put aside the mechanical process and was adapted to photographic processing, which was incredibly faster. In principle, the phototypesetting system was formed by the matrix of characters in negative images processed photographically onto light-sensitive material. However, that system had a big limitation: the magnification of characters. From there on, photocomposition and transfer lettering began to appear, called “Letraset”. (ROCHA, 2005).

3.3 THE DIGITAL REVOLUTION

With the emergence of the first computers, typography was automatically assimilated by those means. The types left the physical support and became binary codes. A typographic font has turned into a digital archive encoded with the descriptions for its visualization on screen (surface responsible for image projection by digital means) and printing output. Those encodings are interpreted directly by the operating system. (ROCHA, 2005).

This digital revolution has broke barriers and spread rapidly. The typographer, that earlier was responsible for the whole printing process and for the creation of movable type, specialized himself, to have command of new technologies for the creation of digital fonts. The Digital typography has surprisingly improved the quality of printed typography due to the more accurate adjustments.

3.4 MIGRATION TO THE WEB ENVIRONMENT

3.4.1 Beginning of the Web Typography

With the web, once again the typography has reached new levels, expanding considerably. Due to the easiness to produce a digital font, the quantity of fonts has multiplied rapidly. In 1993, the Web was driven with the appearance of the first graphical navigator, the NCSA Mosaic (Figure 3), capable of showing images and text in the same screen. For the designers, then a new challenge arose: the creation of layouts for this new environment. However, this new group of navigators used to have the limitation of giving support for an unique font family as standard, necessarily installed in the operating system. (VEEN, 2011).

In this time the HTML was not used to have any specification for the control of its fonts and styles, these were being controlled directly by the browsers. It was only in 1995 that Netscape introduced the tag “<font>”, just standardized in version 2 of HTML. This tag specified a font being used in the rendering of a text, must be installed previously on the computer of the user.

O uso da HTML não dá aos designers de sites um ambiente para a manipulação direta bidimensional. Em lugar disto, fazer o design de um site da Web é como trabalhar com algo disforme. Logo que passamos a outra pessoa, adota uma outra configuração. (SIEGEL, 1999, p. 65).

Figure 3 – Interface of NCSA Mosaic 1.0

Printscreen da interface do NCSA Mosaic 1.0
Source: VEEN, 2011 cited NCSA/University of Illinois

Siegel (1999) already showed dissatisfaction with such typographical limitations and therefore raised the matter of the great challenge to develop a website with a good typography, making it clear that a good typographical result used to be nearly impossible. He also showed the necessity of using the adaptations and tricks to produce nice webpages. Subsequently the tag “<font>”, was discontinued in the HTML specifications, promoting the separation of the HTML content and the styling with the CSS. (FERREIRA, 2011).

The first CSS specification, launched in 1996, definitely removed tags rather exclusive for the HTML styling. Thus, what before used to be treated by the “<font>” tag passed to become part of the CSS and received the following properties: “font-family” (typographical family), “font-style” (italic or normal style), “font-variant” (apllies small caps in the text), “font-weight” (weight) and “font-size” (size). (SIEGEL, 1999).

3.4.2 Fallback Fonts and Generic Font Families

With the CSS attribute “font-family”, it is allowed to use multiple fonts. These fonts are listed, for example, in the following way:

font-family: Helvetica, “Lucida Sans”, Arial;

The first one is the principle one. If the user does not have the features in his machine, automatically the browser will fetch the next from the list, and likewise succesively. That font – chosen for substitution – is called the Fallback Font. In case none of those is found, the browser will show the text with its standard font. The same process occurs when the browser finds a character that is not supported in the character set of the actual font.

Content, used not to have the guarantee that the desired fonts would be installed in the operatifn system of the user, therefore, there used to be the risk that the web design should be displayed in “Arial” were to be displayed in “Times” (typefaces of a completely different design, one serif and the other one sans-serif). To settle that problem a bit, the CSS allowed the utilisation of a generic typographical familiy, declared after all the Fallback Fonts. Example:

font-family: Helvetica, “Lucida Sans”, Arial, sans-serif;

Such families are divided according to the visual characteristics of each on e of them. They are:

  • Sans-serif – Fonts that do not have serifs in the decoration;
  • Serif – Fonts that present serifs;
  • Monospace – Fonts in which all characters the same width, independent of having serifs or not;
  • Cursive – Fonts that mimic the cursive writing;
  • Fantasy – Fonts that have symbols, icons or decorative characters;

3.4.3 Web Safe Fonts

Over time, the navigators (browsers) past the support from one unique font to a quantity of eighteen in 2008. As it used not to be possible to guarantee the the user would have a certain font, the manufacturers of operatins systems intervened with the purpose to facilitate the development of Websites, creating the Web Safe Fonts (Figure 4). Microsoft launched the project Core Fonts for the Web, initiated in 1996 and finalized in 2002 (MICROSOFT, 2002). The project consisted of a package of standard fonts for the Web, distributed for free, with some limitations of use, reaching a high number of users. Since then fonts like “Arial”, “Georgia” and “Verdana” have become standards for the Web.

By becoming pre-installed in the versions of the operating systems after launching this package, the Web Safe Fonts could be used with safety, it is referring to the proper “font-family” of the CSS. Compared to the quantity of fonts in use by the printer, this still used to be a barrier to overcome by the typography on the Web. (VEEN, 2011).

Figure 4 – Set of the Web Safe Fonts

Exemplos das Web Safe Fonts
Ordinary and equivalent fonts in the versions of Windows and Mac. Source: AMPSOFT, 2008

3.4.4 Alternative Solutions: text as image, object or script.

Due to the search of designers to be able to use fonts of their choice in Websites, several solutions were being implemented. Even programmers picked up alternative solutions to utilize fonts directly in the browsers. These searches have driven the evolution of the typography for the Web. Between all the attempts, three solutions were widely used. They are:

The use of text as image – A solution simple and more practical, consists of the substitution of the HTML text by an image containing the same text, though using a non Web Safe font. The positive aspect is that this solution makes it possible to use any font in a Website. The negative aspects, on the other side, are the fact that it blocks the selection of text, increases the use of the bandwidth, it is bad for services of optimazation of research, it is not translatable, generates a degradation of the image in higher resolution and it becomes it becomes inaccessible for whom are using assitance devices. Subsequently, CSS techniques have refined its use, applying the image on top of the HTML text of the page. This eliminates the problems of accessibility and makes the text searchable. (VEEN, 2011).

Text embedded as object (Flash) – The solution is similar to the use of text as image but, this time, it is utilized as a vector file of the Flash software as substitution, with the tag “<object>”. This file was embedded in HTML and the text was rendered as vector. This solution was showing the text better and was not having the problem of undergoing degradation through pictures in high resolution, besides allowing the selection of the text. Its use, however, required a plugin installed on the machine of the client for showing the file. There is still the fact of the resignation of the Apple company to support the format on their devices with the iOS platform, making that users of iPads, iPods and iPhones did not have access to the text with this resouce. (VEEN, 2011).

Rendering of the text by JavaScript – Another implemented solution was the use of scripts in the JavaScript language, that substitute the text by VML – Vector Markup Language (for Internet Explorer) or SVG – Scalable Vector Graphics (for other browsers). These scripts automated the rendering of the text, although, it is not selectable or resizable, and its use for large amounts of text can lead to a bad performance. (VEEN, 2011).

None of the presented solutions was suficiently effective for applicaton in extended blocks of text, working best in short sentences and in titles. Still it has become each time more common in a web development, and this requirement for utilization of fonts besides of the Web Safe Fonts brought the necessity of a standardization with a more adequate solution. (FERREIRA, 2011).

3.4.5 Web Fonts and the @font-face

In 1998 the specification of CCS2 was released. It has the objective to bring improvements for the use of the typography on the Web and was promoting a move forward till then hardly explored. The new specifications have added the rule “@font-face”, that enabled the download of the external font from the Website, making the use of non-preinstalled fonts possible for viewing of the pages. Technically, the rule only makes a link to the file of the font, however, the browser requires to make the download of that file for viewing. In spite of the evolution that this would bring, these new techniques have not had much use in the era and were removed from the specifications of CSS2.1. (MANIAN, 2009).

Greg Veen (2011) attributes to the tireless battle between the browsers in the 90s, or it is, between Internet Explorer and Netscape – with their inconsistent implementations -, one of the reasons for the delay in the use of Web Fonts. Only one decade later, with the drafts of CSS3, the interest for the use of external fonts returned, and again the rule “@font-face” came into effect, treading in this way the typographical move forward so waited for.

In contrast to the official specifications, since its version 4.0, launched in 1997, the browser Internet Explorer has support the native to the “@font-face”. Microsoft implemeted a new fornt format called EOT, existing till the version 8,0 of the browser. Since 2007, one by one, the major graphical browsers started to offer support to the former rule (including browsers for mobile devices) utilizing various formats – the already standard desktop fonts TrueType and OpenType, besides of SVG and WOFF (Web Open Font Format – format that combines technologies of the TrueType and OpenType files, format accepted as standard for the Web Fonts) – and ignoring the EOT of Microsoft. (MANIAN, 2009).

The utilization of a Web Font is simple, sufficing just making a link to the font file which it intends to make use of. In certain cases, the developer can prefer to use the font locally installed on the machine of the user and only make the download when these fonts are not being available. This is possible utilizing “(“local()” in the definition of the file path in the rule “@font-face”. The browser is in charge to make this verification and load only one font. (DAGGETT, 2009).

See the example of usage the following:

    @font-face {
        font-family: Helvetica;
        src: local("Helvetica Neue"),
        url(MinhaHelvetica.ttf);
    }

For Fink (2010), this support was an indispensable piece that was missing in the Web since its appearance, having forms like this is an emergent typographical scenario, dictating a new way, with new possibilities.

4 TYPOGRAPHIC POTENTIALIZATION WITH THE ARRIVAL OF WEB FONTS

4.1 DIGITAL RENDERING OF A FONT

One of the important factors in favor of the use of Web Fonts is that they look much better on the screen. But this is still a factor dependent on browser technologies, operating systems and devices, which creates a challenge in choosing a good Web Font. In order to understand a bit of this problem, we need to know how the digital medium renders the font.

A digital font is a vector file that can be scaled without losing the quality. Its rendering on screen is based on grids of pixels, related to the resolution of the monitors or devices on which they will be shown. That rendering is also affected by interference from operating systems and browsers. That is why a font can be displayed in the same browser with different operating systems in diverse ways, offering better legibility in one than in another. In the following image (Figure 5). the letter “O” appears in a pixel grid, which shows how that rendering is done on a digital screen. In the grid, the pixels can appear as on (with color) or off (without color). According to the size of the font, the operating system calls the pixels that better represent the depiction of the form. However, the system does not always do that in the best way. Observing the image, we see that the representation of the right side is more faithful to the design of the letter “O”, preserving the similarities between the two sides of the character. That is only possible thanks thanks to hinting instructions, which are programmed by the type designer before generating the font file. It is those instructions which guarantee that a glyph retains the appropriate proportions, thus drastically improving the legibility of texts in small sizes and out-of-date browsers. (VEEN, 2011). The hinting comes from being used since the decade of the 80’s, before even of the Web, to improve the rendering in low resolution printers. For Nick Sherman (2013), hinting is to fonts what responsive design is to websites.

Figure 5 – Pixel grid representing the letter “O”

Grid de pixels representando a letra O
The letter “O” on the left side appears deformed, with asymmetrical sides. In the “O” on the right side, it is possible to see the hinting instructions that impose symmetry on the two sides of the character. Source: AHRENS, 2010

The fact that the font performs differently in various browsers means that the designer of the interface had to worry about choosing the ideal Web Font at the beginning of the process. It is necessary to pay attention to the fact that fonts for print don’t always render well on screen, since they don’t have hinting instructions. (VEEN, 2011). Hinting development work is difficult, tedious, lengthy, and expensive. Some automation tools make the work easier, but for small bodies of text, it’s still more appropriate to do manual work. Sherman (2013) expresses the desire of developers to make this concern obsolete with the evolution of screens and rendering software in the future.

The idea of “modifying” characters in different situations is nothing new. Gutenburg was already using optical adjustments for different text sizes (Figure 6), altering spacing, proportion, width and other details to optimize printing. In the same vein, there are already situations where developers detect the conditions for use and provide a specific font for the context. This is another great possibility for typography usage on the Web. (SHERMAN, 2013).

Figure 6 – Comparison of sizes of the letter “a”

Various sizes of the letter “a” from the font Century Expanded from movable type, which use variations to compensate for technical issues in print for greater legibility while preserving its characteristics. Source: SHERMAN, 2013

In rendering, another resource besides hinting is needed. It is for the anti-aliasing to the smoothing of the curves (Figure 7), a process that basically consists of adding semi-transparent pixels on the edges of characters, avoiding aliasing. The efficiency of anti-aliasing depends on hinting and also on softwares and operating systems, and together they are of utmost importance to make the text readable. (GIANNATTASIO, 2009).

Figure 7 – Anti-aliasing comparison

“Goudy Oldstyle Bold” typeface in 42 point body, with and without applying anti-aliasing. Source: GIANNATTASIO, 2009

Anteriormente não existia nenhum controle de como a fonte seria renderizada na Web para o usuário. Com os estudos do CCS3, duas novas possibilidades dão certo controle na entrega do texto em HTML: o já citado “@font-face” e a nova propriedade “font-smooth”.

Tom Giannattasio (2009) defende que, com o “@font-face”, podemos criar um mundo visualmente mais atraente da tipografia na Web, eliminando o uso de fontes locais de baixa qualidade ou fontes feitas para impressão, péssimas para visualização em tela – principalmente em pequenos textos –, e entregando fontes com melhor controle de hinting e mais legíveis. Já a propriedade “font-smooth”, ainda obscura no meio dos desenvolvedores, permite controlar quando a suavização é usada, mas não como, o que é feito pelo sistema do usuário. Ainda não é suportado completamente em todos os maiores navegadores; quando implementado, proverá a capacidade de desabilitar o anti-aliasing, uma boa solução em textos de tamanhos pequenos.

See an example, with its possible values:

font-smooth: auto | never | always | <absolute-size> | length

Cada navegador depende do sistema operacional com sua tecnologia própria para a renderização da fonte. Infelizmente eles podem estar sujeitos a problemas de compatibilidade com os sistemas e renderizarem de forma problemática. Sobre esses aspectos, os designers de interface não possuem controle. According to Tom Giannattasio (2009), the ideal is to understand the nuances of every browser and adapt to every platform.

4.2 STYLISTIC SIMILARITIES AMONG TEXTS IN DIFFERENT LANGUAGES

Seguindo o caminho trilhado hoje pela Web, a tipografia digital vem há algum tempo seguindo padronizações. Por volta de 1987, começaram os estudos para que os computadores pudessem interpretar corretamente caracteres de qualquer tipo de escrita de forma consistente. (UNICODE, 2014).

Esse padrão já é comum em fontes digitais para desktop, e as Web Fonts também o seguem. Ele é tratado internamente pelos sistemas operacionais, porém deve ser corretamente implementado pelos designers de tipos na montagem do arquivo de fonte.

O uso das Web Fonts dá ao designer de interface a possibilidade de manter a similaridade visual de textos com idiomas diferentes, principalmente os não latinos como árabe e japonês, entre outros. Línguas menores e escritas antigas também sofrem com a falta de fontes com suporte adequado. (DAGGETT, 2009). The following image (Figure 8) shows the same font family with similar characteristics in the characters from alphabets like Greek or Cyrillic, preserving proportions of width and height in each one.

Figure 8 – Ubuntu Typeface

Source: MAAG, 2014

O uso de uma Web Font não é necessário somente para suporte de determinado idioma. Muitas vezes é preciso usar pesos ou estilos diferentes no texto (Figura 9), aplicando um negrito ou um itálico, e nem sempre famílias tipográficas possuem mais de um peso. (DAGGETT, 2009).

Figure 9 – M+ font family

Japanese fonts from open source M+ project with various weights. Source: DAGGETT, 2009

A respeito desse uso de negritos e itálicos, uma nova funcionalidade é aguardada. Quando se declara que o texto será negrito ou itálico, e a família da fonte não possui esse peso ou estilo, o navegador irá forçar de alguma forma criando os pesos desejados, resultando assim em uma distorção da tipografia, o que pode ocasionar resultados ruins. Devido a cada implementação de navegador, a renderização de um negrito pode ser mais forte em um e suave em outro. Para controlar essa situação, o CSS3 possui a propriedade “font-synthesis”, que controla se essa distorção pode ou não ser feita pelo navegador. (STEARNS, 2012).

Na figura 10, a fonte “Lora” primeiramente é forçada a ser renderizada em negrito e itálico com as tags “<strong>” e “<cite>” respectivamente. O resultado não é tão ruim, porém o negrito não possui um bom contraste com o resto do texto, e o itálico parece um pouco inclinado demais. Na segunda frase, negrito e itálico são parte da família tipográfica, muito mais condizentes visualmente com o texto.

Figura 10 – Comparison of true and forced bold and italic

Fonte: STEARNS, 2012

4.3 OPENTYPE AND YOUR FEATURES

OpenType is the most recent and modern format for digital fonts. Its benefits include compatibility between platforms, thorough support and a set of characters based on the Unicode pattern. Thanks to OpenType, characters from many different languages can be fitted into one font, supporting more than 65 thousand types and simplifying the multi-language text process. It also counts on resources that prompt a rich linguistic support and an advanced typographical control. (FONTSHOP INTERNATIONAL, 2012).

A single font file may contain many non-standard glyphs, such as old-style figures, tabular figures, small capitals, fractions, swashes, superiors, inferiors, titling letters, contextual and stylistic alternates, a full range of ligatures, symbols and ornaments. The OpenType layout features allow automatic positioning or substitution of glyphs. (FONTSHOP INTERNATIONAL, 2012)

With web browser’s ability to display OpenType fonts, some have also started giving support to resources present in the format. That will be controlled using CSS and a “@font-face” rule, holding its release until the W3C (World Wide Web Constortium, 2014).

Some of such resources are:

Small caps – It turns lower case letters into capitals, keeping the lower case’s height.

Figure 11 – Small caps example

Small caps originals of “Arno Pro” at the second phrase. Fonte: HERRMANN, 2010

Set of figures – The set of figures contains the aligned numerals (numerals that follow the same baselines and height) and the numerals of an old style (numerals that have descenders and ascenders, that are better used in quick text)(Figure 12), follow the tabular proportion (numbers that have the same width) or the proportional (Figure 13). (HERRMANN, 2010).

Figure 12 – Examples of numerals of an old style

In the blue sentence the numerals of old style are applied; the numerals 3 and 6 have descenders and ascenders respectively. Source: HERRMANN, 2010

Figure 13 – Set of figures

Source: Adapted from HERRMANN, 2010

Ligaturas – Junção de letras (Figura 14), que podem ter um propósito estilístico ou histórico. (HERRMANN, 2010).

Figure 14 – Ligature examples

Source: HERRMANN, 2010

Contextual alternates – the ligatures are optional, however, in some cases, depending on the font (Figure 15) or language, it is necessary that the character has substitution according to it’s proportion to or the following character. (HERRMAN, 2010).

Figure 15 – Contextual alternate examples

Source: HERRMANN, 2010

Línguas como o árabe requerem essa substituição para sua escrita, processo em que o caractere é completamente afetado pelos caracteres ao redor (Figura 16). (DAGGETT, 2009).

Figure 16 – Arabic writing example

Source: DAGGETT, 2009

Frações – Um set de caracteres básico em toda fonte possui as frações 1⁄4, 1⁄2 e 3⁄4. Com o OpenType porém é possível a criação de quantas frações forem necessárias (Figura 17). (HERRMANN, 2010).

Figure 17 – Example of fractions

Source: HERRMANN, 2010

Kerning – Ajuste de espaçamento em pares de letras específicos (Figura 18), em parte, uma letra avança sobre o espaço de outra.

Figure 18 – Kerning example

Source: Adapted from STEIN, 2014

4.4 SYMBOLS, ICONS AND MULTICOLORED FONTS

The search for a better performance is a continuous process. The Web went through several site construction architectures, and each one of them was looking for a more efficient standarization. Amongst these processes, we have the use of image sprites (Figure 19), whose concept it’s simple. Basically what it does is to join several small images and icons inside a single image, thus reducing the number of DNS requisitions, improving the performance and the user’s experience. (SUDA, 2013).

Figure 19- Image Sprite from Google.com

Source: [GOOGLE IMAGE SPRITE], 2014

That sprite image concept is transported to Web Fonts. There are already specific Web Fonts (Figure 20) with symbols, icons and decorations and that number doesn’t stop growing. They have the same benefits – reduce file size, reduced requisitions, while also enjoying render power in high resolution – and substitute many images of the site with a simple font archive. (SUDA, 2013).

Figure 20 – Glyphicons typeface

Some of the icons available in the Glyphicons typeface. Source: GLYPHICONS, 2014

With accessibility in mind, the use of web fonts for symbols has to be planned and careful. Some fonts map the symbols using letters; for example when typing “E” would be renderized the figure from an envelope on the browser. Trouble can happen when sending the font fails (figures 21 and 22), resulting in rendering characters in random places, that do not make sense. So, it is necessary to recur to CSS to round those issues. One of the solutions given by Brian Suda (2013) is the use of correct direct text in HTML and the insertion of symbols by CSS’ pseudo-elements “:before” or “:after”. That way, if you wish to use an icon for a link that takes you to another page, the text of the link “next page” will be hidden, and the icon of an arrow will be presented via CSS. The author points that this problems could be solved if fonts followed Unicode’s correct patterns for those symbols. These special characters are not connected semantically with no letter of the alphabet. And if the font is not loaded, only an empty box will be displayed substituting the character instead of a letter.

Figure 21 – Page of the site @CRAIGMOD

Complete loading of the site with Web Font. Source: LYNAM; MOD, 2009

Figure 22 – Page of the site @CRAIGMOD

Carregamento incompleto com falha no download da Web Font Fonte: LYNAM; MOD, 2009

Ampliando ainda mais o uso dos ícones e símbolos em Web Fonts, Suda (2013) recorre ao uso das ligaturas OpenType, incentivando a ideia de que se pode fazer o uso de substituições da seguinte forma. Ao usar um texto com o seguinte dizer “A List Apart”, ele será convertido completamente para um único símbolo representando o logotipo do site A List Apart.

Apesar das vantagens de se usar uma fonte com ícones ou símbolos, elas possuem uma barreira ainda em estudo: as fontes somente aceitam uma única cor. Até é possível o uso de degradês, com algumas técnicas CSS para emular duas cores, mas, se necessário o uso de múltiplas cores, atualmente é preciso retornar ao uso dos sprites de imagens. Em vista de resolver essa situação, as empresas de sistemas operacionais começaram a propor soluções com fontes multicoloridas, por exemplo a Apple, que trouxe a fonte Apple Color Emoji (Figura 23). (SUDA, 2013).

Figure 23 – Apple Color Emoji Typeface

Source: HERRMANN, 2013

A solução proposta pela Apple e também pela Google utiliza um arquivo PNG para gerar o caractere e, com isso, consegue usar múltiplas cores. Já o Windows vem com uma proposta diferente (Figura 24), introduzindo o suporte de vetores em camada, sendo que cada camada recebe uma cor (Figura 25). (HERRMANN, 2013).

Figure 24 – Segoe UI Emoji Typeface

Source: HERRMANN, 2013

Figure 25 – Color scheme layered

Source: HERRMANN, 2013

Certamente as fontes de ícones e símbolos estão sendo fortemente impulsionadas e padronizadas com a expansão das Web Fonts devido à grande aceitação, sendo agora as fontes multicoloridas um novo avanço tipográfico que, embora já existente, ainda se encontra em estado de estudo, aguardando uma boa aceitação e padronização. Conforme Siegel (1999), os designers deveriam concentrar-se nas coisas que eles podem influenciar e esperar futuramente por melhores padrões, sendo as fontes multicoloridas apenas um exemplo de tecnologia a que esses profissionais devem se atentar. Sendo assim, designers precisam se manter atentos às tecnologias, a fim de poderem continuar impulsionando ainda mais o campo tipográfico e aprimorando seus conhecimentos.

5 ONGOING RESPONSIBILITY OF INTERFACE DESIGNERS IN THE CONTEXT OF WEB FONTS

Before the implementation of the rule “@font-face”, the use of external fonts was limited, without a widely-implemented technical solution. Today, with the use of this new rule, along with the expansion of Web Fonts, designers have been encouraged to evaluate their possibilities, in a scenario of convergence of the nuances of printed typography with the the dynamics of the Web. (LYNAM; MOD, 2009). Thus, it remains for the designers to understand those new advances and updates even more in a context as dynamic as the one of the Web which goes through constant modifications, always searching to obtain better standards and resources which take into account the needs of programmers and designers.

The arrival of the Web Fonts promises to get ride of any typographical monotony, till now dominated by the Web Safe Fonts, giving to the designer the possibility to select whatever font for his layout. (HERRMANN, 2011). However, such liberty requires careful selection and needs to be analyzed thoroughly. Um dos requisitos mais ignorados para uma seleção adequada ao projeto são os fatores histórico-culturais conectados ao tipo da fonte. Muitos estilos estão atrelados a períodos históricos, e é preciso saber em que momento essas fontes foram desenvolvidas, buscando conhecer o propósito para o qual foram feitas. Às vezes a fonte parece ser visualmente adequada, mas pode gerar uma má interpretação. Por exemplo, fontes góticas (Figura 26) são mais pesadas, escuras e afiadas, sendo mais adequadas quando se quer transmitir uma ideia de medo ou escuridão (Figura 27). Esse conhecimento usado de forma inteligente potencializa uma boa escolha e traz maior clareza ao usuário. (MARIA, 2009).

Figure 26 – Example of gothic typeface

Source: REYNOLDS, 2010

Figure 27 – Example of gothic arquitecture

Source: SIVYER, 2011

Siegel (1999) said that “…uma boa tipografia deve procurar facilitar as coisas para o leitor, não desafiá-lo”. The author expresses the idea that the typography must be good. However a good usage of typography does not depend only on a good font, but a good choice. Para isso, o designer deve compreender o projeto como um todo, suas características, objetivos, suporte, aplicação, público-alvo, aspectos culturais e necessidades especiais. Uma boa seleção leva em conta a legibilidade, sendo que algumas fontes são mais legíveis em tela do que outras, e essa legibilidade é em parte influenciada pela altura-de-x (altura das letras minúsculas) e a altura total da fonte (LYNCH; HORTON. 2008), que por sua vez também sofrem influência direta dos recursos de renderização já mencionados anteriormente.

Após tais conceitos terem sido compreendidos e levados em consideração, e uma fonte ou família tipográfica adequada ter sido selecionada para o projeto, o designer passa a contar com os recursos OpenType avançados para a otimização tipográfica. Tais recursos propiciam ajustes mais apurados, com uma ampla gama de substituições automáticas e ajustes de espaçamento específicos para pares de letras. E por mais atuais que esses novos recursos possam parecer, é importante ressaltar que, no âmbito tipográfico, muitos deles já existiam e vêm sendo aprimorados desde os tipos móveis, sendo adaptados para o meio em que a tipografia se espalhou. Recursos como kerning, versaletes, letras caudais, ligaturas (Figura 28 e 29), etc, existentes já na tipografia digital, somente agora podem ser usados nativamente na Web sem nenhum recurso adicional. Portanto é responsabilidade do designer saber e utilizar regras que remontam do início da tipografia até hoje (BOULTON, 2005), regras estas extremamente úteis e aplicáveis no ambiente Web. Conforme Reichenstein (1996a), a tipografia é uma disciplina antiga que requer muito estudo e esforço repetitivo, e na prática ela não se resume a escolher ou criar fontes, mas se relaciona ao objetivo de modelar o texto para uma experiência de leitura ideal.

Figure 28 – Example of ligature “ft” of the typeface “Garamond” in movable metal type.

Source: ULLRICH, 2006

Figure 29 – Example of ligature “ft” of the digital typeface “Garamond”.

Source: MICO, 2013

Optimizing typography is to improve readability, accessibility, and usability. Sua organização em blocos de texto e junção com imagens é o que os profissionais vêm aprimorando desde os primórdios tipográficos, portanto não devem ser negligenciados. Any designer can use a beautiful typeface, but good professionals treat the text as an important part of the interface, ensuring good read across the majority of browsers and platforms, the correct usage of line spacing, spacing between letters, breathing room and a good contrast, to help with good readability. Somente ter o trabalho de escolha de fonte para um projeto não é o suficiente, mas um bom uso tipográfico pode, inclusive, ser feito somente com uma única família. (REICHENSTEIN, 2006b). O uso de uma boa tipografia garante unidade gráfica, e a seleção de uma família confere consistência. Executando corretamente tais requisitos, não será necessário ter a certeza de que um site será exibido igual em várias plataformas e dispositivos, mas é necessário apurar sua facilidade de uso e de leitura. (REICHENSTEIN, 2006a).

Dominando tais conhecimentos em relação aos atuais recursos por parte do designer, é obrigação do mesmo compartilhar tais conhecimentos com desenvolvedores, atualmente ainda os responsáveis pela codificação dos layouts, aplicando corretamente tais recursos. Porém, essa responsabilidade pode voltar a se concentrar futuramente somente no designer com a melhora de programas capazes de codificar o layout.

6 CONCLUSION

The use of the typography as the basis of the written communication passed through a long road evolving to digital media. In the latter, their use extrapolated all that had been done, and inserted in the Web (initially with limited support, now with the expansion of Web Fonts) brought with it the prospect of visual enhancements with the release of the use of any typographical and family with features that enable advanced controls that influence in a better reading. As has been happening on the Web from the beginning, the way to stabilize Web Fonts is the standardization. Some discussions are still in force, as the form of your application and what format will be accepted by the W3C. With this standardization, all browsers will have to adapt, thus eliminating the current conflicts of formats. Before an official standardization, however, the picture is of an exponential expansion. Using Web Fonts is done by a large number of sites, and have already begun to see them expanding their potential, absorbing the sprites from images with symbol fonts and icons. This practice has spread in website development and is well accepted by the developer community.

The Web Fonts bring with features already implemented before in digital fonts for desktop and printing. The OpenType typographic features expand control and provide possibilities of using some unexplored by developers and interface designers. Keeping in mind that none of these technological resources are new in the typographic world, having their origins on the mobile types. Thus, currently, designers have the role of developers share with your prior typographic knowledge, so that together we can reach the objectified result in the production of the layout. With the possible expansion of programs that cut the layout, generating code, designers have a tool that can work without interference depend on the Developer as the codification of the layout, but such programs need to have implemented these new typographic features.

With the evolution of monitors and display screens as well as the high definition retina screen technology, the meticulous manual work to control hinting soon will no longer be necessary, giving the designer more liberty in the choice of font, thus bringing improvements in the rendering and, consequently, in the readability.

For the future, we already see signs of a new typographic expansion, given the still very limited for use and without a set, in a scenario where companies fight to create a format that is accepted by all format multicolored sources. As they arise tools that enable its creation, designers can give utilities hitherto unexplored.

Given such update, the designers have a responsibility to continue their improvement, not leaving behind his previous typographic knowledge, that, in the creation of interfaces, use typography as an ally, integrating it to the interface, giving more clarity in communication with the user. Its interface must meet the current devices and screens such as Smart TVs, but also be prepared for new devices such as SmartWatchs, browsers and not as common as the one in the consoles Xbox, Playstation, etc.

REFERENCES

Web Engineering: state of the art and comparisons with conventional software engineering

The growing use of the Internet and thus the Web is beginning to transform the market of information systems. However, the capacity to run and plan these ever larger and more complex systems is not keeping up with this growth. One can see that there still isn’t, in the majority of cases, a well-defined and organized process, the ad hoc model being the most used. Therefore, it has become necessary to create a discipline that can address the specific characteristics of web-based applications, Web Engineering (WebE). In this article, the engineering and the characteristics of Web applications are discussed via a literature review; additionally, a comparison between conventional Software Engineering and WebE is also presented.

1 Introduction

The Word-Wide-Web (WWW) is a relatively new medium, but it endures constant changes. Despite the novelty, it is already integrated in our lives and widely used by organizations all over the world, breaking international barriers. Its significant impact and the great importance it has acquired, whether in the corporate world or even beyond it in personal sites, in education, and the entertainment sectors, are making the demand for applications in this medium grow exponentially.

To carry out the development of these applications, the great majority of developers end up forced to choose the ad hoc model of development, due to the lack of a specific methodology. Such applications are developed in chaotic fashion and with margins for errors and faults that compromise the integrity of the system, in addition to a deficiency in documentation for the product and process.

Para tentar cobrir essa lacuna, uma nova área do saber foi criada, a Engenharia Web (Web Engineering), que incorpora princípios do desenvolvimento de software padrão, buscando entender as necessidades específicas da Web e assim solucionar os problemas relacionados ao desenvolvimento. Tendendo a criação de um modelo de processo com ciclo de desenvolvimento repetível e eficiente, e produzindo uma metodologia de avaliação adequada, que contribua com a compreensão e melhora da qualidade das aplicações Web.

Muitos aspectos relativos ao desenvolvimento Web o tornam diferente ao de um software tradicional. Temos a escalabilidade de seus requisitos e a necessidade das mudanças contínuas em seu conteúdo como os dois atributos-chave citados por [Ginige(2001)]. De extrema relevância temos a multidisciplinaridade, e entre as características críticas temos a segurança, a usabilidade e também a manutenabilidade.

Além disso, no processo de produção para uma aplicação Web, é necessário o esforço integrado de profissionais de várias áreas do saber. À medida que aumentam a complexidade e sofisticação dos novos sistemas, uma melhor abordagem sistemática, controle de qualidade e garantia são exigidos, e uma melhor metodologia contribui para um desenvolvimento harmônico, estruturado e bem integrado nos aspectos multidisciplinares.

2 Characteristics Of The Web Application Development

Para [Pressman(2006)], uma aplicação Web pode ser desde uma simples página, a um Web Site completo. Esses sistemas são orientados a documentos que contenham páginas estáticas ou dinâmicas, e são centrados na aparência e nas sensações. Tais aplicações se aproveitam do meio e fazem uma interligação dos conteúdos existentes, dando ao usuário final acesso fácil para edição e criação do mesmo, sustentados por ferramentas amplamente difundidas. Seus provedores são Web designer, redatores, dentre outros.

[Powel(1998)] relata que a mistura encontrada em sistemas Web, envolve a publicação impressa e o desenvolvimento de software, entre o marketing e a computação, entre as comunicações internas e as relações externas e entre a arte e a tecnologia. Mencionada a natureza da engenharia Web, sua equipe é obrigatoriamente multidisciplinar, abrangendo áreas como interação homem-computador, interface com o usuário, análise de sistemas e design, engenharia de software, engenharia de requisitos, engenharia de hipermídia, engenharia de requisitos, testes, modelagem e simulação e gerenciamento de projetos, bem como ciências sociais, artes gráficas e projeto (Figura 1) [Murugesan (1999)].

Campos da Engenharia Web
Figure 1. Web engineering – A multidisciplinary field

O processo de desenvolvimento para Web apresentado por [Rodriguez(2002)], divide o processo em dois sub-processos:

  • sub-processo de autoria, onde ocorre a estruturação de hipermídia.
  • sub-processo de desenvolvimento de infraestrutura, onde é feita integração com base de dados, programação, etc.

Ambos os processos são realizadas nos fluxos de trabalho do processo de desenvolvimento de software convencional. Já a proposta de [Ward & Kroll(1999)] para o desenvolvimento de aplicações Web é a unificação do processo criativo de design ao de engenharia de software proposto pelo Rational Unified Process (RUP). Para isso é usada a modelagem de requisitos, baseada em casos de uso, com a abordagem focada em aspectos de autoria, com diagramas de navegação, conteúdo e layout de interfaces. Estudos também apontam que o desenvolvimento pode ser feito em paralelo, adotando-se um processo que separa as atividades relacionadas aos aspectos de autoria e de infraestrutura em sub-processos paralelos.

Outra característica das aplicações que estão sendo discutidas é o curto ciclo de vida da fase de desenvolvimento. A exigência do mercado para que os sistemas estejam disponíveis o mais breve possível contribuí para tal aspecto. Por tratar-se de alcance global, as aplicações Web possuem grande concorrência e qualquer tempo desperdiçado pode culminar em prejuízos.

Por ser um ambiente complexo e dinâmico a avaliação dessas aplicações é dificultada. Com a diversidade de objetivos, diferentes aspectos são avaliados. Para uma boa avaliação da qualidade final das Aplicações Web, adotamos características tais como funcionalidade, usabilidade, confiabilidade, eficiência, manutenabilidade e portabilidade [ISO91]. Já em outro modelo de avaliação proposto é sugerido que o desenvolvimento das aplicações Web é um esforço contínuo e que progride através de diversos estágios definidos. Suas fases de desenvolvimento são: conceitualização, desenvolvimento, implementação e avaliação. Sendo que estas fases são interligadas constituindo-se um ciclo recorrente.

Portanto, a criação de uma disciplina que seja capaz de avaliar esta qualidade e acompanhar todos os processos que envolvem a construção de sistemas para Web se faz necessária. Na sessão seguinte será abordada esta emergente disciplina, a Engenharia Web.

3 Web Engineering

Como dito anteriormente, nos últimos anos, os sistemas Web estão tornando-se cada vez maiores e mais complexos. Além disso, para desenvolver estes sistemas, é necessária uma equipe heterogênea, com grande variedade de conhecimentos e habilidades [Ginige (2002)]. Por estes motivos, é essencial a utilização de uma metodologia que seja capaz de gerir esta equipe e todo o processo que tange a construção das aplicações.

A Engenharia Web (WebE – da sigla em inglês Web Engineering), caracteriza-se como uma disciplina emergente [Ahmad (2005)] cujo objetivo é possibilitar o desenvolvimento, implantação e manutenção de aplicações baseadas na Web. Utiliza abordagens sistemáticas e princípios científicos de gerenciamento [Murugesan (1999)] para a construção destas aplicações. Dentre os seus objetivos encontram-se a facilitação da manutenibilidade e escalabilidade, minimização dos riscos e principalmente a melhoria e garantia da qualidade do produto de software Web.

Desde 1998, vêm ocorrendo workshops e conferências que abordam a WebE. A crescente utilização da Internet e a ampliação dos sistemas Web não só nos computadores pessoais como também nos dispositivos móveis faz com que haja uma preocupação cada vez maior com o processo de desenvolvimento deste tipo de sistema. A variedade das tecnologias, a multidisciplinaridade, além da contínua evolução e volatilidade dos requisitos que os sistemas Web apresentam são características importantes quando se discute a engenharia Web.

Segundo Pressman [Pressman (2000)], as seguintes atividades devem ser consideradas quando o assunto é a WebE: formulação, planejamento, análise, modelagem, geração de página e teste, além da avaliação do cliente. Ainda segundo o autor, estas atividades devem ser realizadas de maneira iterativa à medida que o sistema evolui.

A WebE segue conceitos e princípios da engenharia de software tradicional enfatizando as mesmas técnicas e atividades de gestão [Ahmad (2005)]. Apesar de possuírem atividades em comum, a engenharia Web não é um “clone” da engenharia de software [Pressman (1986)]. As diferenças entre as duas disciplinas serão explicitadas a seguir.

4 Web Engineering vs. Software Engineering

Neste capítulo serão apresentadas diferenças entre a engenharia Web e a engenharia de software. Mesmo que o objetivo de ambas seja a programação e o desenvolvimento de sistemas, a WebE apresenta novos desafios [Ginige (2001)]. A principal diferença é a multidisciplinaridade que as aplicações baseadas na Web apresentam.

Segundo [Ginige (2001)], esta multidisciplinaridade resulta na contribuição para áreas como engenharia de hipermídia e hipertexto, desenvolvimento de interfaces, interação homem-computador, engenharia da informação, design gráfico e áreas afins. Por este motivo, [McDonald (2001)] conclui que a engenharia Web deve levar em conta os diferentes tipos de profissionais envolvidos no processo garantindo que cada um entenda seu papel e responsabilidade. Além disso, deve ser capaz de resolver os conflitos dos limites destes papéis e responsabilidades levando em conta o que é melhor para o projeto.

[McDonald (2001)] ainda discute sobre outras características que a engenharia Web deve possuir para atender as demandas que uma aplicação Web exige e que se diferenciam da engenharia de software:

  • Devido ao curto ciclo de desenvolvimento e curtos prazos para entrega do produto final bem menores que aplicações desktop, a engenharia Web deve ser capaz de lidar com esta pressão.
  • Por ser ligada não somente ao desenvolvimento em si, mas também ser orientada ao conteúdo a engenharia Web deve preocupar-se também com o desenvolvimento dos dados e da informação bem como o relacionamento entre eles.
  • As equipes devem ser quebradas em partes menores assim como em um processo de desenvolvimento de software convencional.
    Entretanto, estas equipes devem poder ir além dos seus pares de trabalho e além de seus projetos para evitar esforços redundantes e garantir consistência.
  • Deve haver um foco maior na fase de análise e avaliação e nas fases de requisitos e testes.
  • Deve ser independente de tecnologia e ferramentas devido à rápida e contínua evolução das mesmas.

Além das características apresentadas é importante ressaltar que a Engenharia Web deve ter um foco maior para a segurança e qualidade do que a engenharia convencional. O fato de estarem disponíveis em uma rede de alcance mundial – a Internet – faz com que ataques sejam mais frequentes e qualquer brecha de sistema pode ser fatal. A segurança está diretamente ligada à qualidade que depende da aplicação de uma engenharia e processo bem definidos.

5 Conclusions

O crescimento e a complexidade das aplicações baseadas na Web preocupam àqueles que trabalham e pesquisam esta área. Por este motivo, a utilização da Engenharia Web vem sendo cada vez mais discutida e pesquisada. Apesar de ser uma disciplina praticamente recente sua importância já é destacada.

Existem diferenças entre a WebE e a engenharia de software convencional. Estas diferenças ocorrem devido à natureza das aplicações Web. As mesmas exigem um prazo de desenvolvimento mais curto, envolvem diversas áreas de conhecimento – são multidisciplinares, possuem um foco maior na informação e estão em constante evolução.

Por estes motivos, a Engenharia Web caracteriza-se por ser bastante flexível. Deve ser independente de tecnologia, capaz de gerir as diversificadas equipes, focar na análise e planejamento para que problemas possam ser evitados. Além disso, deve abranger não só o desenvolvimento de software em sim como também a segurança, o design e o desenvolvimento e apresentação da informação.

6 References

  • Ahmad, R.; Zhang Li; Azam, F.; “Web engineering: a new emerging discipline,” Emerging Technologies, 2005. Proceedings of the IEEE Symposium on , vol., no., pp. 445-450, 17-18 Set. 2005.
  • Athula Ginige. 2002. Web engineering: managing the complexity of web systems development. In Proceedings of the 14th international conference on Software engineering and knowledge engineering (SEKE ’02). ACM, New York, NY, USA, 721-729.
  • Ginige, A.; Murugesan, S.; , “Web engineering: an introduction,” Multimedia, IEEE, vol.8, no.1, pp.14-18, Jan-Mar 2001.
  • ISO/IEC 9126 Standard for Information Technology, Software Product Evaluation – Quality Characteristics and Guidelines for their use, Geneve,1991.
  • McDonald A., Welland R.: Web Engineering in Practice, Proceedings of the Fourth WWW10 Workshop on Web Engineering, 21-30, (1 May 2001).
  • Murugesan, S. et al. (1999). Web engineering: A New Discipline for Development of Web-based systems. InProceedings of the First ICSE Workshop on Web Engineering, Los Angeles (pp. 1-9).What a Tangled Web We Weave.
  • Powell, T.A, Web Site Engineering: Beyound Web Page Design, Prentice Hall, 1998.
  • Pressman, R. Engenharia de Software, McGraw Hill, 6a ed., 2006.
  • Pressman, R.S.; , “What a tangled Web we weave [Web engineering],” Software, IEEE , vol.17, no.1, pp.18-21, Jan/Feb 2000
  • Pressman. 1986. Software Engineering: a Practitioner’s Approach (4th Ed.). McGraw-Hill, Inc., New York, NY, USA.
  • Rodriguez, D.; Harrison, R. & Satpathy, M. A Generic Model and Tool Support for Assessing and Improving Web Processes”. Proceedings of the Eighth IEEE Symposium on Software Metrics. IEEE, 2002.
  • Ward, S. & Kroll, P. Building Web Solutions with the Rational Unified Process: Unifying the creative design process and the software engineering process. Context Integration Inc and Rational Software. 1999.

Engenharia Web: estado da arte e comparativo com a engenharia de software convencional

A crescente utilização da Internet e consequentemente da Web começa a transformar o mercado dos sistemas de informação. Entretanto, a capacidade de gerir e planejar estes sistemas cada vez maiores e mais complexos não acompanha este crescimento. Percebe-se que ainda não há, na maioria das vezes, um processo bem definido e organizado, sendo o modelo ad hoc o mais utilizado. Portanto, faz-se necessária a criação de uma disciplina que possa atender às características específicas das aplicações baseadas na Web, a Engenharia Web (WebE). Neste artigo a engenharia e as características das aplicações Web são discutidas através de uma revisão de literatura, além disso, um comparativo com a Engenharia de Software convencional e a WebE também é apresentado.

1 Introdução

A Word-Wide-Web (WWW) é um meio relativamente novo, mas que sofre mudanças a todo instante. Apesar da novidade, ela já se instalou em nossas vidas e vem sendo utilizada amplamente por organizações pelo mundo, quebrando barreiras internacionais. O impacto significante e a grande importância adquirida, seja no mundo corporativo ou até mesmo fora dele, em páginas pessoais, na educação e no setor de entretenimento, fez com que a demanda de aplicações nesse meio crescesse exponencialmente.

Para suprir o desenvolvimento dessas aplicações, a grande maioria dos desenvolvedores acaba sendo obrigada a escolher o modelo ad hoc de desenvolvimento, por falta de uma metodologia específica. Tais aplicações são desenvolvidas de forma caótica e dando margem para erros e falhas que comprometem a integridade do sistema, além da deficiência na documentação do produto e do processo.

Para tentar cobrir essa lacuna, uma nova área do saber foi criada, a Engenharia Web (Web Engineering), que incorpora princípios do desenvolvimento de software padrão, buscando entender as necessidades específicas da Web e assim solucionar os problemas relacionados ao desenvolvimento. Tendendo a criação de um modelo de processo com ciclo de desenvolvimento repetível e eficiente, e produzindo uma metodologia de avaliação adequada, que contribua com a compreensão e melhora da qualidade das aplicações Web.

Muitos aspectos relativos ao desenvolvimento Web o tornam diferente ao de um software tradicional. Temos a escalabilidade de seus requisitos e a necessidade das mudanças contínuas em seu conteúdo como os dois atributos-chave citados por [Ginige(2001)]. De extrema relevância temos a multidisciplinaridade, e entre as características críticas temos a segurança, a usabilidade e também a manutenabilidade.

Além disso, no processo de produção para uma aplicação Web, é necessário o esforço integrado de profissionais de várias áreas do saber. À medida que aumentam a complexidade e sofisticação dos novos sistemas, uma melhor abordagem sistemática, controle de qualidade e garantia são exigidos, e uma melhor metodologia contribui para um desenvolvimento harmônico, estruturado e bem integrado nos aspectos multidisciplinares.

2 Características do desenvolvimento de Aplicações Web

Para [Pressman(2006)], uma aplicação Web pode ser desde uma simples página, a um Web Site completo. Esses sistemas são orientados a documentos que contenham páginas estáticas ou dinâmicas, e são centrados na aparência e nas sensações. Tais aplicações se aproveitam do meio e fazem uma interligação dos conteúdos existentes, dando ao usuário final acesso fácil para edição e criação do mesmo, sustentados por ferramentas amplamente difundidas. Seus provedores são Web designer, redatores, dentre outros.

[Powel(1998)] relata que a mistura encontrada em sistemas Web, envolve a publicação impressa e o desenvolvimento de software, entre o marketing e a computação, entre as comunicações internas e as relações externas e entre a arte e a tecnologia. Mencionada a natureza da engenharia Web, sua equipe é obrigatoriamente multidisciplinar, abrangendo áreas como interação homem-computador, interface com o usuário, análise de sistemas e design, engenharia de software, engenharia de requisitos, engenharia de hipermídia, engenharia de requisitos, testes, modelagem e simulação e gerenciamento de projetos, bem como ciências sociais, artes gráficas e projeto (Figura 1) [Murugesan (1999)].

Campos da Engenharia Web
Figura 1. Engenharia Web – Um campo multidisciplinar

O processo de desenvolvimento para Web apresentado por [Rodriguez(2002)], divide o processo em dois sub-processos:

  • sub-processo de autoria, onde ocorre a estruturação de hipermídia.
  • sub-processo de desenvolvimento de infraestrutura, onde é feita integração com base de dados, programação, etc.

Ambos os processos são realizadas nos fluxos de trabalho do processo de desenvolvimento de software convencional. Já a proposta de [Ward & Kroll(1999)] para o desenvolvimento de aplicações Web é a unificação do processo criativo de design ao de engenharia de software proposto pelo Rational Unified Process (RUP). Para isso é usada a modelagem de requisitos, baseada em casos de uso, com a abordagem focada em aspectos de autoria, com diagramas de navegação, conteúdo e layout de interfaces. Estudos também apontam que o desenvolvimento pode ser feito em paralelo, adotando-se um processo que separa as atividades relacionadas aos aspectos de autoria e de infraestrutura em sub-processos paralelos.

Outra característica das aplicações que estão sendo discutidas é o curto ciclo de vida da fase de desenvolvimento. A exigência do mercado para que os sistemas estejam disponíveis o mais breve possível contribuí para tal aspecto. Por tratar-se de alcance global, as aplicações Web possuem grande concorrência e qualquer tempo desperdiçado pode culminar em prejuízos.

Por ser um ambiente complexo e dinâmico a avaliação dessas aplicações é dificultada. Com a diversidade de objetivos, diferentes aspectos são avaliados. Para uma boa avaliação da qualidade final das Aplicações Web, adotamos características tais como funcionalidade, usabilidade, confiabilidade, eficiência, manutenabilidade e portabilidade [ISO91]. Já em outro modelo de avaliação proposto é sugerido que o desenvolvimento das aplicações Web é um esforço contínuo e que progride através de diversos estágios definidos. Suas fases de desenvolvimento são: conceitualização, desenvolvimento, implementação e avaliação. Sendo que estas fases são interligadas constituindo-se um ciclo recorrente.

Portanto, a criação de uma disciplina que seja capaz de avaliar esta qualidade e acompanhar todos os processos que envolvem a construção de sistemas para Web se faz necessária. Na sessão seguinte será abordada esta emergente disciplina, a Engenharia Web.

3 Engenharia Web

Como dito anteriormente, nos últimos anos, os sistemas Web estão tornando-se cada vez maiores e mais complexos. Além disso, para desenvolver estes sistemas, é necessária uma equipe heterogênea, com grande variedade de conhecimentos e habilidades [Ginige (2002)]. Por estes motivos, é essencial a utilização de uma metodologia que seja capaz de gerir esta equipe e todo o processo que tange a construção das aplicações.

A Engenharia Web (WebE – da sigla em inglês Web Engineering), caracteriza-se como uma disciplina emergente [Ahmad (2005)] cujo objetivo é possibilitar o desenvolvimento, implantação e manutenção de aplicações baseadas na Web. Utiliza abordagens sistemáticas e princípios científicos de gerenciamento [Murugesan (1999)] para a construção destas aplicações. Dentre os seus objetivos encontram-se a facilitação da manutenibilidade e escalabilidade, minimização dos riscos e principalmente a melhoria e garantia da qualidade do produto de software Web.

Desde 1998, vêm ocorrendo workshops e conferências que abordam a WebE. A crescente utilização da Internet e a ampliação dos sistemas Web não só nos computadores pessoais como também nos dispositivos móveis faz com que haja uma preocupação cada vez maior com o processo de desenvolvimento deste tipo de sistema. A variedade das tecnologias, a multidisciplinaridade, além da contínua evolução e volatilidade dos requisitos que os sistemas Web apresentam são características importantes quando se discute a engenharia Web.

Segundo Pressman [Pressman (2000)], as seguintes atividades devem ser consideradas quando o assunto é a WebE: formulação, planejamento, análise, modelagem, geração de página e teste, além da avaliação do cliente. Ainda segundo o autor, estas atividades devem ser realizadas de maneira iterativa à medida que o sistema evolui.

A WebE segue conceitos e princípios da engenharia de software tradicional enfatizando as mesmas técnicas e atividades de gestão [Ahmad (2005)]. Apesar de possuírem atividades em comum, a engenharia Web não é um “clone” da engenharia de software [Pressman (1986)]. As diferenças entre as duas disciplinas serão explicitadas a seguir.

4 Engenharia Web vs. Engenharia de Software

Neste capítulo serão apresentadas diferenças entre a engenharia Web e a engenharia de software. Mesmo que o objetivo de ambas seja a programação e o desenvolvimento de sistemas, a WebE apresenta novos desafios [Ginige (2001)]. A principal diferença é a multidisciplinaridade que as aplicações baseadas na Web apresentam.

Segundo [Ginige (2001)], esta multidisciplinaridade resulta na contribuição para áreas como engenharia de hipermídia e hipertexto, desenvolvimento de interfaces, interação homem-computador, engenharia da informação, design gráfico e áreas afins. Por este motivo, [McDonald (2001)] conclui que a engenharia Web deve levar em conta os diferentes tipos de profissionais envolvidos no processo garantindo que cada um entenda seu papel e responsabilidade. Além disso, deve ser capaz de resolver os conflitos dos limites destes papéis e responsabilidades levando em conta o que é melhor para o projeto.

[McDonald (2001)] ainda discute sobre outras características que a engenharia Web deve possuir para atender as demandas que uma aplicação Web exige e que se diferenciam da engenharia de software:

  • Devido ao curto ciclo de desenvolvimento e curtos prazos para entrega do produto final bem menores que aplicações desktop, a engenharia Web deve ser capaz de lidar com esta pressão.
  • Por ser ligada não somente ao desenvolvimento em si, mas também ser orientada ao conteúdo a engenharia Web deve preocupar-se também com o desenvolvimento dos dados e da informação bem como o relacionamento entre eles.
  • As equipes devem ser quebradas em partes menores assim como em um processo de desenvolvimento de software convencional.
    Entretanto, estas equipes devem poder ir além dos seus pares de trabalho e além de seus projetos para evitar esforços redundantes e garantir consistência.
  • Deve haver um foco maior na fase de análise e avaliação e nas fases de requisitos e testes.
  • Deve ser independente de tecnologia e ferramentas devido à rápida e contínua evolução das mesmas.

Além das características apresentadas é importante ressaltar que a Engenharia Web deve ter um foco maior para a segurança e qualidade do que a engenharia convencional. O fato de estarem disponíveis em uma rede de alcance mundial – a Internet – faz com que ataques sejam mais frequentes e qualquer brecha de sistema pode ser fatal. A segurança está diretamente ligada à qualidade que depende da aplicação de uma engenharia e processo bem definidos.

5 Conclusões

O crescimento e a complexidade das aplicações baseadas na Web preocupam àqueles que trabalham e pesquisam esta área. Por este motivo, a utilização da Engenharia Web vem sendo cada vez mais discutida e pesquisada. Apesar de ser uma disciplina praticamente recente sua importância já é destacada.

Existem diferenças entre a WebE e a engenharia de software convencional. Estas diferenças ocorrem devido à natureza das aplicações Web. As mesmas exigem um prazo de desenvolvimento mais curto, envolvem diversas áreas de conhecimento – são multidisciplinares, possuem um foco maior na informação e estão em constante evolução.

Por estes motivos, a Engenharia Web caracteriza-se por ser bastante flexível. Deve ser independente de tecnologia, capaz de gerir as diversificadas equipes, focar na análise e planejamento para que problemas possam ser evitados. Além disso, deve abranger não só o desenvolvimento de software em sim como também a segurança, o design e o desenvolvimento e apresentação da informação.

6 Referências

  • Ahmad, R.; Zhang Li; Azam, F.; “Web engineering: a new emerging discipline,” Emerging Technologies, 2005. Proceedings of the IEEE Symposium on , vol., no., pp. 445-450, 17-18 Set. 2005.
  • Athula Ginige. 2002. Web engineering: managing the complexity of web systems development. In Proceedings of the 14th international conference on Software engineering and knowledge engineering (SEKE ’02). ACM, New York, NY, USA, 721-729.
  • Ginige, A.; Murugesan, S.; , “Web engineering: an introduction,” Multimedia, IEEE, vol.8, no.1, pp.14-18, Jan-Mar 2001.
  • ISO/IEC 9126 Standard for Information Technology, Software Product Evaluation – Quality Characteristics and Guidelines for their use, Geneve,1991.
  • McDonald A., Welland R.: Web Engineering in Practice, Proceedings of the Fourth WWW10 Workshop on Web Engineering, 21-30, (1 May 2001).
  • Murugesan, S. et al. (1999). Web engineering: A New Discipline for Development of Web-based systems. InProceedings of the First ICSE Workshop on Web Engineering, Los Angeles (pp. 1-9).What a Tangled Web We Weave.
  • Powell, T.A, Web Site Engineering: Beyound Web Page Design, Prentice Hall, 1998.
  • Pressman, R. Engenharia de Software, McGraw Hill, 6a ed., 2006.
  • Pressman, R.S.; , “What a tangled Web we weave [Web engineering],” Software, IEEE , vol.17, no.1, pp.18-21, Jan/Feb 2000
  • Pressman. 1986. Software Engineering: a Practitioner’s Approach (4th Ed.). McGraw-Hill, Inc., New York, NY, USA.
  • Rodriguez, D.; Harrison, R. & Satpathy, M. A Generic Model and Tool Support for Assessing and Improving Web Processes”. Proceedings of the Eighth IEEE Symposium on Software Metrics. IEEE, 2002.
  • Ward, S. & Kroll, P. Building Web Solutions with the Rational Unified Process: Unifying the creative design process and the software engineering process. Context Integration Inc and Rational Software. 1999.