16º Simpósio Nacional de Geometria Descritiva e Desenho Técnico V International Conference on Graphics Engineering for Arts and Design
Santa Cruz do Sul, RS - Brasil - 08 - 11 Setembro de 2003
UM MÉTODO DE WEB DESIGN BASEADO EM
USABILIDADE
Maria Laura Martinez1
Universidade de São Paulo, Brasil
Departamento de Jornalismo e Editoração - Escola de Comunicações e Artes Departamento de Sistemas Eletrônicos - Escola Politécnica
RESUMO
Como atestam numerosos estudos de usabilidade, perde-se muito com web sites mal feitos. Pode parecer fácil desenvolver um web site: qualquer um com ferramentas modernas de edição HTML pode publicar informação. Contudo, fazer um site eficiente e profissional, que realmente atenda ao usuário, é uma tarefa complexa. A Web introduziu uma complexidade nova para a usabilidade nunca vista antes no software tradicional. A usabilidade em web sites é uma área importante, em plena expansão, com características particulares que dificultam sua pesquisa. Este artigo apresenta um método para desenvolvimento de web sites baseado em engenharia de usabilidade, tema central da tese da autora. O método aborda o web design respeitando a percepção do usuário, otimizando a comunicação e atingindo o público de forma mais eficiente.
Palavras Chaves: Web design; usabilidade; metodologia; engenharia de
software.
ABSTRACT
As demonstrated by numerous usability studies, a lot is lost with poorly developed web sites. It seems to be easy to develop a web site: anyone with modern HTML edition tools can publish information. However to make an efficient and professional site is a complex task. The Web introduced a new complexity for the usability, never seen before in traditional software. Web site usability is an important growing research area with particular characteristics that make its study difficult. This paper presents a method for web sites development based on usability engineering, central subject of the author's thesis. The method approaches web design respecting the user's perception, optimizing the communication and reaching the public in a more efficient way.
Key-words: Web design; usability; methodology; software engineering.
1
1
Introdução
A palavra design abrange mais do que a idéia da representação pictórica ou de leiaute gráfico. Engloba todo o processo no qual se insere a representação ou o desenvolvimento do leiaute, processo este que não pode ser dissociado do elemento humano que o concebe, que o produz ou que se relaciona com o seu resultado.
1.1 O problema
A HTML é uma linguagem de descrição de páginas e não de programação, o que a torna relativamente fácil de utilizar. Hoje existem ferramentas que permitem compor com facilidade páginas Web, sem necessidade de se conhecer o código. Estas ferramentas, apesar de permitirem a produção de páginas simples, muitas vezes dificultam a implementação de um leiaute mais elaborado, impedindo ao designer, desconhecedor da HTML, ter um controle maior do visual da sua obra. Outras vezes inserem um grande volume de código espúrio, que aumenta o tamanho da página (em bytes) e torna sua visualização mais lenta. Outras ainda, inserem código das últimas versões da linguagem HTML, somente interpretado pelos browsers mais novos, prejudicando uma parcela do público que ainda utiliza navegadores de versões mais antigas.
Por outro lado, saber fazer uma página ou um site não garante o sucesso na comunicação da informação ou do uso da aplicação, como constataram diversos autores. Conforme ROCHA (2000): "Dados disponíveis apontam que em 1998, cerca de três bilhões de dólares deixaram de ser ganhos na Web norte-americana por causa de design mal feito de páginas, que dificultava a compra em vez de facilitar.” [a IBM] “...constatou que o recurso mais popular em seu site era a função de busca, porque as pessoas não conseguiam descobrir como navegar, e o segundo mais popular era o botão ajuda. A solução foi um amplo processo de redesign, envolvendo centenas de pessoas e milhões de dólares. Resultado: na primeira semana depois do redesign, em fevereiro de 1999, o uso do botão de ajuda caiu 84% enquanto as vendas aumentaram 400%.”
Para NIELSEN (1999), nem sempre o meio está sendo usado para facilitar a vida do usuário e não é raro ver pessoas frustradas ou perdidas em sites mal feitos.
Sites mal projetados têm conseqüências de grande impacto que trazem perda de dinheiro e de credibilidade. Sites comerciais perdem seus clientes frustrados, antes que efetuem a compra. Leitores desnorteados em sites noticiosos o abandonam antes de encontrar a informação procurada. Alunos em sites educacionais mal projetados não conseguem atingir seus objetivos de aprendizagem. E pessoas frustradas migram com facilidade ao site do concorrente, que está apenas a um clique do mouse.
A questão que surge é: como fazer um web site eficiente que realmente atenda ao usuário?
1.2 A Usabilidade
A norma ISO 9241-11, define a usabilidade como: a efetividade, a eficiência e a satisfação com que usuários específicos atingem objetivos específicos em ambientes particulares.
Mesmo sendo um conceito conhecido desde a década de 80, somente nos últimos anos a palavra 'usabilidade' começou a ser melhor investigada e tornou-se crítica com o surgimento da Web. Conforme NIELSEN (1999), as conseqüências de uma interface gráfica pobre em usabilidade são muito piores quando esta é implementada na Web do que quando é implementada em software tradicional.
Curiosamente, apesar da Web ter popularizado a usabilidade, acrescentou-lhe novos e grandes desafios. A Web constitui um novo meio de comunicação e tem uma
linguagem própria construída sobre um espaço hipermídia complexo, com características particulares de acesso remoto a dados, publicação dinâmica de informações, interfaces gráficas mutantes, velocidades de conexão variáveis, rápida absorção de novidades tecnológicas, entre outras (MARTINEZ 2000).
Em projetos de software, a usabilidade é mais eficiente quando aplicada logo no começo do ciclo de desenvolvimento. Os primeiros 10% do processo de design determinam 90% do produto e é quando são tomadas as decisões-chave do projeto. Conforme GILB (1988), não corrigir um problema de usabilidade na fase de design custa 10 vezes mais se o sistema está em desenvolvimento e 100 vezes mais se o sistema já foi lançado.
Entre as principais razões para adotar a usabilidade desde cedo em um projeto pode-se citar: redução de erros e de procedimentos de correção; redução do tempo de operação da interface; redução de custos de treinamento, de manutenção e de suporte ao usuário e, como conseqüência, o aumento da eficiência e da efetividade da interface para o seu público.
1.3 À procura de soluções
O processo genérico de desenvolvimento hipermídia, tem sido abordado por alguns métodos como HDM: Hypertext Design Model (GARZOTTO, 1993), RMM: Relationship Management Methodology (ISAKOWITZ, 1995) y OOHDM: Object-Oriented Hypertext Design Model (SCHWABE, 1995). Estes métodos requerem que o domínio a aplicação seja abstraído em forma de entidades (ou classes) e de relações e, segundo LOWE (1999), tendem a ser mais prescritivos, no sentido em que guiam o processo mas não fornecem indicações de como adaptá-lo aos diferentes domínios de aplicação. Lowe et al. propõem um modelo de referência para o desenvolvimento hipermídia que pode ser instanciado tanto como prescritivo quanto descritivo, no sentido em que também descreve o processo.
MAYHEW (1999), apresenta um modelo descritivo do processo genérico de desenvolvimento de software em Engenharia de usabilidade que consta de três etapas: a análise de requisitos, o design/testes/desenvolvimento e a instalação. Mayhew faz algumas breves observações sobre as possibilidades de aplicação do método para a Web, mas estas não são desenvolvidas nem especializadas. Por outro lado, os outros métodos de desenvolvimento de aplicações hipermídia, listados anteriormente, não são centrados em usabilidade nem levam em conta as particularidades do processo de desenvolvimento Web.
A seguir, são apresentadas as principais características do método de desenvolvimento de web sites baseado em usabilidade proposto como tese da autora que aperfeiçoa e enriquece o método publicado em MARTINEZ (2001).
O método foi utilizado e avaliado com sucesso no projeto do web site da Agência Universitária de Notícias do curso de Jornalismo da USP2. Os resultados deste estudo de caso (muito extensos para este artigo), estão documentados em MARTINEZ (2002).
O método estende e especializa para a Web o método de MAYHEW (1999). Adota o ciclo estrela de HIX (1989), baseado em avaliação de usabilidade, pelo dinamismo e maior flexibilidade que propicia a todo o processo. Por fim, baseia-se na experiência da autora no desenvolvimento de web sites, área na qual trabalha desde 1995.
2
O método
O diagrama da figura 1, a seguir, apresenta o método proposto. Os retângulos representam as tarefas, ou módulos, do ciclo de Engenharia de Usabilidade. As setas representam a ordem mais provável de realização de tarefas. Algumas das seqüências de
2
tarefas são iterativas e os lugares onde estas iterações normalmente ocorrem são representados por setas pontilhadas retornando a pontos anteriores do ciclo de vida.
No método proposto, os principais grupos foram rotulados por um retângulo deformado em onda (e.g. 'Análise de Requisitos', 'Especificação de Conteúdo', 'Especificação de Layout', e assim por diante).
A seta pontilhada na horizontal, entre as etapas de Especificação de Conteúdo e de Implementação indica um atalho para o projeto de web sites simples.
O método proposto distingue três etapas principais:
• o Planejamento (que contém a análise de requisitos, as especificações de conteúdo, de leiaute gráfico, de implementação e de distribuição);
• a Implementação (que é formada pelo 'dadoduto' de implementação)
• a Distribuição. (que é formada pela publicação e pela divulgação)
Todas as etapas são permeadas e intermediadas por avaliação de usabilidade3.
Distribuição Implementação Instalação e configuração server-side Avaliação Guia de Estilo Avaliação Iterativa Coleta e criação de conteúdo Preparação dos dados Lapidação Mapeam.Arquitet. de Informação Estatísticas Estratégias Manutenção Atend. público Feedback FEITO atende às metas de usabilidade? atende a todas as funcionalidades? tudo resolvido? tudo resolvido? Planejamento Metas de Usabilidade Perfil do Usuário Análise de Tarefas Guidelines e Princípios de Webdesign Análise de Plataforma Cliente Análise de Sites similares Análise de necessidades Análise funcional Guia de Estilo Guia de Estilo Restrições implement. Armazena-mento lógico Análise client side e server side Avaliação Iterativa Protótipo Gráfico Padrões de Design da Tela Avaliação Iterativa Planejamento de Tarefas Maquete Definição de Metáforas Arquitetura Informação Restrições acesso/ segu. Especifica atendimento Especifica manutenção Estratégias divulgação Estimativa de Demanda e de Plataforma servidora elimina os principais defeitos? atende às metas de usabilidade? Guia de Estilo Guia de Estilo Prototipação HTML Publicação Especific. de conteúdo Especific. de layout Análise de Requisitos Especific. implement Especific. distribuição Divulgação melho-rias [MARTINEZ,01]
Figura 1: As etapas do método proposto.
3
Breve descrição das etapas do método
43.1 Análise de Requisitos
O objetivo da Análise de Requisitos é fazer o modelamento das metas de usabilidade do web site, em função das análises do usuário, da aplicação e de princípios gerais de web design.
3
Para uma descrição de técnicas de avaliação de usabilidade consultar (WINCKLER,1999), (NIELSEN,1993), (RUBIN,1994), (IVORY,2001), (MAYHEW,1999) e (RAVDEN,1989).
4
A realização de cada módulo do método é intermediada por algum tipo de avaliação, muitas vezes embutida na própria técnica de execução.
Assim, a análise de perfil e de tarefas do usuário pode ser realizada através de entrevistas, questionários, avaliações remotas ou testes em laboratório. A análise de plataforma cliente é baseada no feedback do usuário fornecido em resposta a questionários. O mesmo ocorre com a análise funcional e de necessidades da aplicação, baseadas no conhecimento de especialistas e na análise de sites similares, baseada em avaliação heurística e empírica dos mesmos. Recomendações e princípios de web design, como as 10 heurísticas de NIELSEN (1994), são incorporados ao projeto e também guiam a inspeção de usabilidade de sites similares. No fim desta etapa são estabelecidas metas de usabilidade baseadas nos cinco atributos de NIELSEN (1993)5, que guiam o restante do desenvolvimento.
Em projetos de web sites de grande porte, todas as decisões e resultados de cada etapa do método devem ser incorporadas à documentação de um Guia de Estilo que dará homogeneidade e consistência ao trabalho da equipe.
3.2 Especificação de conteúdo
A etapa de especificação de conteúdo preocupa-se em melhorar o modelo de tarefas do usuário, incorporando as funcionalidades definidas anteriormente e tornando mais eficientes suas práticas de trabalho. Preocupa-se também em aproximar ao seu modelo mental (sobre como realizar tarefas), o modelo conceitual da aplicação que será definido em termos da reengenharia de tarefas, da especificação de metáforas e de arquitetura de informação.
No fim desta etapa obtém-se recomendações de alto nível sobre as funcionalidades da aplicação, sobre a escolha de metáforas e sobre as informações das principais telas da aplicação. Também obtém-se um esboço da rede de nós e links que forma o esqueleto hipermídia do site.
Toda a Especificação de conteúdo é independente de plataforma cliente. As metáforas são regras genéricas de apresentação, que consideram somente o nível mais alto do design da interface. Somente na próxima etapa de Especificação de layout gráfico, a interface receberá um design detalhado em sintonia com a análise de plataforma cliente e com as metas de usabilidade.
A avaliação de usabilidade nesta etapa é feita sobre os esboços das telas e do esqueleto hipermídia, procurando determinar se estão de acordo com as especificações do guia de estilo e se os principais problemas conceituais foram eliminados. As técnicas (e os critérios de avaliação) devem ser escolhidos em conformidade com o tipo de projeto e suas necessidades.
3.3 Especificação de layout
A Web introduziu uma necessidade maior de imagem, diferenciação de mercado e marcas corporativas do que no software tradicional.
Alguns autores (como BLACK,1997), apontam que uma página na Web deve se parecer a um outdoor de estrada no sentido em que deve conseguir brevemente comunicar sua mensagem e deixar sua marca ('a apenas um olhar') quando o usuário está de passagem. Isto porque usuários são infrequentes, têm muitas opções e, normalmente, pouco tempo para explorá-las.
A habilidade de se trabalhar a imagem desta forma não é comumente encontrada em Designers de Interface de Usuário, nem em Engenheiros de Usabilidade. Designers
5
São eles: facilidade de aprendizagem, eficiência de uso, facilidade de memorização, baixa taxa de erros e satisfação subjetiva.
gráficos são mais qualificados para trabalhar a comunicação através da imagem e definir a apresentação visual dos modelos de trabalho, o que torna sua participação fundamental nesta etapa do projeto.
Esta etapa basicamente se preocupa em definir como será a apresentação gráfica da aplicação, em sintonia com os resultados da análise de plataforma cliente (e.g. resolução da tela em pixels, resolução de cor, fator gama das plataformas, entre outros), de acordo com as metáforas escolhidas e com os tipos de telas definidos durante a arquitetura de informação.
O resultado é um conjunto de protótipos gráficos dos principais tipos de páginas do site, que podem ser desenhados com editores de imagens.
Somente na atividade de 'Implementação', as páginas serão prototipadas em HTML e os protótipos gráficos, desenvolvidos nesta etapa, serão utilizados posteriormente para gerar as imagens (geralmente GIFs), que comporão as telas.
Para interfaces simples e que não precisam de um tratamento gráfico diferenciado, não há necessidade da prototipação gráfica utilizando um editor de imagens, pode-se passar diretamente para a prototipação HTML que caracteriza a atividade de Implementação.
A definição de padrões de design de tela, é refinada iterativamente a partir de avaliação de usabilidade.
3.4 Especificação de implementação
Antes da implementação do site planejado nas etapas anteriores, é necessário tomar decisões que fazem grande diferença para o sucesso do desenvolvimento. Elas são relacionadas à lógica do armazenamento dos arquivos em disco (a organização dos mesmos em diretórios e subdiretórios e a definição de regras para seus nomes), às restrições de implementação e às soluções do lado do cliente e do lado do servidor (client-side e server-side), a ser adotadas.
As restrições de implementação, são muito importantes para garantir o bom funcionamento do sistema em diferentes plataformas cliente, atendendo às diversas demandas de desempenho. Estas podem ser elaboradas com a ajuda de um especialista em web design e conhecedor das tecnologias online. São algumas delas: restrições ao formato e tamanho dos arquivos, ao armazenamento em cache (definidas pela data de validade do conteúdo), e à forma de referenciar os links (de forma absoluta ou relativa).
Soluções do lado do cliente e do lado do servidor (client-side e server-side), devem ser escolhidas cuidadosamente para garantir o bom funcionamento da aplicação online. Programas JavaScript ou Applets são essencialmente executados do lado do cliente, assim como plug-ins; enquanto programas CGI, API's, middlewares (como PHP ou ASP) e Sistemas Gerenciadores de Banco de Gados são executados do lado do servidor. Quando um programa muito solicitado é executado do lado do servidor pode sobrecarregar o processamento da máquina ou ainda comprometer a segurança do sistema. Por outro lado, um programa projetado para rodar do lado do cliente pode não encontrar as condições adequadas para ser processado naquela plataforma.
3.5 Especificação de distribuição
Nesta etapa devem ser definidas: as restrições de acesso e segurança, como será feita a manutenção, o atendimento ao usuário e as estratégias de divulgação que deverão ser adotadas.
Em web sites nos quais se espera grande tráfego, também deve ser feita uma estimativa de demanda do sistema no lado do servidor. Isto permite fazer uma seleção adequada da plataforma servidora a partir da qual será distribuído o web site e adotar estratégias que diminuam a sobrecarga de processamento. Na estimativa de demanda
deve-se analisar que programas rodam simultaneamente, quantos usuários simultâneos se espera na pior situação de uso e quais as exigências de desempenho impostas por este processamento, estabelecendo o quanto de degradação de performance poderá ser admitida.
As restrições de acesso e segurança permitirão garantir a correta distribuição do conteúdo. Podem ser elaboradas com a ajuda de especialistas em segurança na Internet e devem atender às outras especificações do projeto. A especificação destas restrições é utilizada na configuração do servidor Web, na implementação de programas de bloqueio de acesso, de encriptação de dados ou de filtros para robots (i.e. programas indexadores dos mecanismos de busca).
Normalmente ao se publicar um site se esquece da importância de manter as informações atualizadas e do atendimento ao público... e muitos sites que têm potencial para sucesso acabam falindo. Por isto é importante de antemão definir estratégias para abordar estas duas questões.
Na Internet existem milhões de web sites e esse número cresce com o tempo. Um site a mais não terá visibilidade a não ser que adote algumas estratégias simples de divulgação para sua distribuição. São alguns exemplos: solicitar a catalogação por mecanismos de busca, divulgar sua existência através de listas de e-mail, colocar links em outros sites visíveis (conhecidos) para o web site em questão, inserir meta-tags de palavras chave e descrição de conteúdo nas páginas HTML, participar de concursos de web sites conhecidos pelo público e divulgados pela mídia, ou ainda, utilizar os métodos tradicionais de divulgação como TV, radio, outdoors.
3.6 Implementação
Esta atividade depende das decisões de projeto tomadas na etapa anterior. Pode ocorrer que, durante a implementação, se encontrem falhas no projeto inicial e este tenha que ser modificado novamente, seguindo a liberdade de se movimentar no ciclo estrela. Quanto melhor seja feito o projeto inicial, menor o tempo que deverá ser gasto durante esta etapa. Implementação Implementação Protótipo HTML Preparação dos dados Mapeamento da Arquitetura de Informação Lapidação Coleta e criação de conteúdo Avaliação Iterativa Avaliação Iterativa WSA / Protótipo HTML Dados Derivados Dados Iniciais
Figura 2: O dadoduto para a atividade de Implementação.
Uma vez coletado ou criado um dado, ele passará por uma seqüência de etapas, de transformações e relacionamentos, que o prepara para sua publicação. Observa-se a formação de um duto de dados (que será chamado de 'dadoduto'6) que se inicia com sua coleta e termina com a implementação do protótipo HTML, conforme esquematizado pela figura 2, anterior. A identificação do dadoduto permite um melhor gerenciamento dos recursos do projeto e da equipe, conforme é explicado adiante.
6
As funcionalidades são implementadas em camadas (primeiro as mais prioritárias) e cada funcionalidade pode ser refinada passando mais de uma vez através do dadoduto.
Na implementação de web sites podem ser identificados alguns níveis característicos de passagem pelo dadoduto, que foram representados na figura 3, a seguir.
No nível (a) são criados os templates HTML das páginas que são baseados nos templates gráficos identificados na Especificação de conteúdo e desenhados na Especificação de layout. Estes templates serão linkados conforme o esqueleto hipermídia definido na etapa de Arquitetura de Informação. Obtém-se finalmente um Web site Abstrato (WSA), ainda sem nenhum conteúdo de informação, formado pelos templates das principais categorias de páginas que serão relacionados pela estrutura de navegação definida pela Especificação de conteúdo.
O nível (b) é seguido somente por sites que integram a publicação Web com servidores de Banco de Dados (BD). Nele é implementado o modelo físico do BD projetado durante a Especificação de implementação. Os programas middleware (que fazem a 'ponte' entre o servidor Web e o de BD), são codificados e otimizados, e então são relacionados ao esqueleto de templates HTML, desenvolvido no nível (a), anterior. No fim obtém-se um WSA relacionado ao banco de dados, mas ainda sem conteúdo de informação. Durante a avaliação iterativa, é verificado se os programas middleware estão funcionando corretamente, introduzindo dados para teste.
nível (c) nível (c) Conteúdo nível (b) nível (b) Integração com BD nível (a) nível (a) Templates linkados Embute em template HTML Coleta / Cria conteúdo de informação Otimiza / Trata Conteúdo •Transforma • Otimiza / Trata Conteúdo Cadastra no BD Otimiza imagens e HTML Linka Templates HTML • Templates Gráficos. • Recorta GIFs • Codifica Template HTML Template HTML Otimizado WSA Otimiza código middleware Associa código middleware aos templates HTML Implementa: • BD • middleware BD e programas programas otimizados WSA •Transformações de comunicação •Ajuste fino Protótipo HTML Preparação dos dados Mapeamento da Arquitetura Informação Lapidação Coleta e criação de conteúdo WSA / Protótipo HTML Dados Derivados Dados Iniciais Conteúdo Conteúdo Otimizado Protótipo HTML Protótipo HTML
Figura 3: O dadoduto sendo aplicado em diferentes níveis.
No nível (c) o conteúdo de informação do web site é coletado, tratado e anexado aos templates HTML. Este relacionamento entre conteúdo e páginas HTML pode ser feito de forma direta (embutindo o conteúdo diretamente no código HTML dos templates) ou de forma indireta (cadastrando o conteúdo no Banco de Dados, que fará a publicação automática). No fim deste processo o web site passa pela lapidação onde são aplicadas técnicas de visualização ou de design de informação7 para melhor representar o conteúdo e é feito o ajuste fino da diagramação (e.g. alinhamentos, espaçamentos, etc). Finalmente obtém-se o protótipo HTML.
Durante a avaliação iterativa, são verificados os padrões de design de tela, se a funcionalidade implementada nessa passagem pelo dadoduto está completa e operando, se os links estão corretamente conectados, se foram utilizadas as restrições de
7
Técnicas de visualização ou design de informação podem ser encontradas em (BERTIN,1983) (MACKINLAY,1986) (TUFT,1990) (ZIMMERMAN,1997) ou (JACOBSON,1999).
implementação definidas anteriormente e se o armazenamento lógico dos arquivos em disco foi feito conforme especificado. No caso de integração com Banco de dados, deve ser feito um teste de como um determinado template gerencia diferentes conteúdos (e.g. como fica a aparência da página quando um campo textual inclui seu maior e seu menor texto).
3.6.1 A gerência dos recursos do projeto
A observação dos três níveis de passagem pelo dadoduto, permite gerenciar melhor os recursos do projeto e da equipe.
Conforme mostra a figura 4, a seguir, pode ocorrer de se ter mais de um nível, sendo implementado em paralelo. O eixo horizontal da figura representa as etapas do dadoduto (tarefas) distribuídas no tempo. O eixo vertical à esquerda representa os três níveis descritos anteriormente (a, b e c).
tempo níveis colet a / criaçã o prepa ração / tratam ento mape amen to designer gráfico & programador programador & administrador conteudista & programador
templates linkados (a) integração BD (b) conteúdo (c)
equipe (tarefas no tempo)
Figura 4: Distribuição no tempo de tarefas, níveis e equipe, permitida pelo dadoduto. Percebe-se que no nível a tem-se basicamente tarefas de design gráfico e codificação HTML e o mesmo pode ser executada por um designer gráfico e um programador. Para desenvolver o nível b (i.e. implementar os bancos de dados e os programas de integração) bastam as habilidades do programador e do administrador de rede. No nível c, é importante o papel do conteudista (i.e. um especialista na aplicação) que pode ser ajudado por um programador e um especialista em design de informação.
Os três níveis podem ser executados no tempo em paralelo, tomando o cuidado de sincronizar as atividades. Por exemplo: os templates HTML do nível a já devem ter sido finalizados quando os programas middleware do nível b estiverem sendo concluídos (para que possam ser integrados).
Pode-se tirar vantagem das características do dadoduto principalmente ao se desenvolver web sites que envolvem uma equipe de produção (i.e web sites médios e grandes), de forma a gerenciar melhor a alocação dos recursos computacionais e de equipe. Esta qualidade do dadoduto, não deve ser notada na produção de web sites muito simples com um único desenvolvedor.
3.7 Distribuição
A distribuição é a terceira atividade do método e compreende a publicação (a implantação do sistema) e a divulgação do site.
Durante a etapa de publicação o protótipo HTML final é colocado online. Para isto, os arquivos são copiados para um diretório reconhecido pelo servidor Web, é feita a configuração da plataforma servidora e são instalados e configurados os outros programas server-side, como servidor FTP, programas que executam as restrições de acesso e segurança (e.g. senhas), servidor Banco de Dados e programas middleware. Ao se copiar os arquivos para baixo do servidor Web, podem ser introduzidos novos
problemas não detectados durante as avaliações de usabilidade feitas no fim da implementação (sobre o protótipo rodando nas máquinas locais). Assim, é necessário fazer uma nova avaliação local (checando se todos os links e as funcionalidades implementadas estão operando corretamente e se as imagens e demais mídias estão sendo carregadas) e outra remota (checando a velocidade de transmissão das páginas).
Durante a etapa de divulgação são executadas as estratégias definidas anteriormente durante a Especificação de distribuição.
Algum tempo após executar as estratégias de divulgação do site é útil gerar estatísticas de acesso para saber qual o retorno obtido, confirmando se as metas definidas para a divulgação do site foram atingidas. Caso contrário, novas medidas de publicidade devem ser adotadas. Existem muitos programas de domínio público que fazem a análise estatística. Entre as medidas mais importantes das estatísticas de acesso, estão os hits, pageviews sessões e usuários únicos8, mas também podem ser extraídas outras informações como número médio de pedidos atendidos (e não atendidos) em um dado período e o tráfego médio em bytes por período. Existem alguns problemas que podem comprometer as estatísticas de acesso, em especial, o uso de cache pelo browser e/ou pelo servidor de proxy.
Uma vez que esteja tudo resolvido, o web site está pronto para ser submetido aos processos de manutenção e de atendimento ao usuário definidos anteriormente e que serão repetidos durante toda a sua vida útil. O contato com o usuário tem que ser incentivado. Um canal de comunicação bem atendido dá credibilidade ao web site e permite identificar problemas novos ou que não tenham sido detectados anteriormente.
No fim, o web site implementa uma versão da aplicação ou um "protótipo pronto" ou ainda uma camada de funcionalidades. Novas camadas do projeto anterior podem ser implementadas em sucessivos ciclos de implementação / distribuição.
4
Conclusões
O método proposto se baseia e modifica aquele de usabilidade de [MAYHEW,00]. Introduz as análises funcional, de necessidades e de web sites similares, que fornecem indicações de como adaptá-lo aos diferentes domínios de aplicação. Introduz a definição de metáforas e a especificação da arquitetura de informação, que procuram definir e organizar o conteúdo do site de forma consistente com o modelo mental do usuário. Introduz o planejamento da implementação e da distribuição, fundamentais para prever e evitar muitos dos problemas do desenvolvimento de web sites. Contribui com a idéia de 'dadoduto' que estabelece etapas claras para o processo de implementação Web permitindo a otimização da gerência do projeto. Também identifica processos importantes no ciclo de publicação e introduz a etapa de divulgação, necessários para a existência e a sobrevivência de um web site.
Muitos exemplos podem ser extraídos do estudo de caso em MARTINEZ(2002) e fazem acreditar que o método tornou-se realmente um diferencial durante o ciclo de desenvolvimento, conseguindo-se resultados que dificilmente teriam sido atingidos sem ele. As reflexões levantadas durante este trabalho fazem acreditar que o método se revela útil tanto para web sites complexos quanto simples. No entanto, para web sites muito simples é necessário que se escolham atalhos e técnicas simplificadas, para não se correr o risco de transformar o desenvolvimento em algo demorado e complicado além do necessário. Técnicas como análise heurística e pequenos testes com usuários podem ser muito reveladores para qualquer desenvolvedor, principalmente em projetos de pequeno porte.
8
Agradecimentos
Ao LSI-Poli-USP e ao CJE-ECA-USP por todo o apoio. Em especial, ao Prof. João Antônio Zuffo pela confiança, incentivo e orientação. Ao Prof. Proença, pela essencial cooperação e pelo entusiasmo com que estimulou o estudo de caso. À Profa. Roseli de Deus Lopes, ao Prof. Sérgio Leal e à Profa. Ana Magda pelo importante encorajamento e colaboração. À Profa. Lúcia Filgueiras e aos colegas e mentores do ILCE (Instituto Latinoamericano de la Comunicación Educativa) pelos valiosos ensinamentos. À OEA pela bolsa que permitiu que fosse ao México realizar o curso no ILCE. Ao Prof. Romero Tori e ao Prof. Eduardo Toledo Santos, pelas sugestões.
Referências
[1] BERTIN,J. Semiology of graphics. The University of Wisconsin Press, Madison,
Wisconsin, 1983.
[2] GARZOTTO,F.; PAOLINI,P.; SCHWABE,D. HDM: a model based approach to
hypermedia application design. ACM Transactions on Information Systems, 11(1): pg.1-26. 1993.
[3] HIX,D; HARTSON,R. Human-computer interface development: concepts and systems for
Its management. ACM Computing Surveys 21(1): 5-92. 1989.
[4] ISAKOWITZ,T.; STOHR,E., BALASUBRAMANIAN,P. RMM: a methodology for
structured hypermedia design. Comm.of the ACM, V.38, N.8, pg.34-44. August, 1995.
[5] IVORY,M.Y.; HEARST,M.A. The state of the art in automating usability evaluation of
user interfaces. ACM Computing Surveys, V.33, N.4, pg.470-516. December, 2001.
[6] JACOBSON,R. editor. Information Design. The MIT Press, London, England. 1999. 357p.
[7] LOWE,D.B.; BUCKNELL,A.J.; WEBBY,R. Improving hypermidia development: a
reference model-based process assessment method. In: 10th. ACM Conference on Hypertext and Hypermedia, Proceedings. Darmstat, Germany, pg.139-146. 1999.
[8] MACKINLAY,J. Automating the design of graphical presentations of relational
information, ACM Transactions on Graphics, v.5, n.2, pg.110-1, 1986.
[9] MARTINEZ,M.L. Usabilidade no design gráfico de Web sites. In: GRAPHICA'2000 III
International Conference on Graphics Engineering for Arts and Design & 14o Simpósio Nacional de Geometria Descritiva e Desenho Técnico. Anais em CDROM, Ouro Preto -MG - Brasil. Jun./2000.
[10] MARTINEZ,M.L. Un método de diseño Web basado en usabilidad para la
comunicación efectiva de la información. In: GRAPHICA'2001 IV International Conference on Graphics Engineering for Arts and Design & 15o Simpósio Nacional de Geometria Descritiva e Desenho Técnico. Anais em CD-ROM. São Paulo, SP, Brasil. Nov./2001.
[11] MARTINEZ,M.L. Um método de webdesign baseado em usabilidade.
São Paulo, 2002. 301p. Tese (Doutorado) - Escola Politécnica. Universidade de São Paulo, Brasil.
[12] MAYHEW,D.J. The usability engineering lifecycle (formerly managing the design of
the user interface). In: ACM CHI’98, Proceedings, 18-23, pg. 127-128. April, 1998.
[13] MAYHEW,D.J. The usability engineering lifecycle: a practitioner’s handbook for
user interface design. Morgan Kaufmann Publishers. Março, 1999.
[14] NIELSEN, J. Usability engineering. Academic Press Inc., Boston, USA. 1993.
[15] NIELSEN,J. Ten usability heuristics. In. NIELSEN,J.;MACK,R. (eds) Usability
inspection methods. New York, John Wiley & Sons, 1994. http://www.useit.com/papers/heuristic/heuristic_list.htm.
[16] NIELSEN, Jacob. Web usability: past, present and future. 8/Ago. 1999.
http://webword.com/interviews/nielsen.html.
[17] RAVDEN,S.; JOHNSON,G. Evaluating usability of human-computer interfaces: a
[18] ROCHA, H.V.; BARANAUSKAS,M.C.C. Design e avaliação das interfaces
humano-computador. 12ª Escola de Computação, São Paulo, IME-USP, 2000.
[19] RUBIN,J. Handbook of usability testing: how to plan, design and conduct effective
tests. John Wiley & Sons, Inc. 1994.
[20] SCHWABE,D.; ROSSI,G. The object-oriented hypermedia design model. . Comm.of
the ACM, V.38, N.8, pg. 45-46. August, 1995.
[21] TUFTE,E.R. Envisioning information. Graphics Press. May, 1990.
[22] WINCKLER,M.A.A. Proposta de uma metodologia para avaliação de usabilidade
de interfaces www. Porto Alegre, março de 1999. Dissertação (Mestrado) - Instituto de
Informática. Universidade Federal do Rio Grande do Sul.
[23] ZIMMERMAN,B.B. Applying Tufte’s principles of information design to creatin
effective Web sites. In: The 15th Annual International Conference on Computer Documentation, Proceedings, pg.309-317. 1997.
