exame de qualificação - LabES
Transcrição
exame de qualificação - LabES
EXAME DE QUALIFICAÇÃO UNIVERSIDADE FEDERAL DE SÃO CARLOS CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO “Investigando o Uso de Senso Comum no apoio à Formalização de Patterns Motivacionais para Aplicações Web” ALUNA: Ana Luiza Dias ORIENTADORA: Profa. Dra. Junia Coutinho Anacleto São Carlos Fevereiro/2008 CAIXA POSTAL 676 FONE/FAX: (016) 33518233 13565-905 – SÃO CARLOS – SP BRASIL RESUMO Atualmente, o trabalho colaborativo tem se tornado cada vez mais presente devido à globalização e a necessidade de cumprir tarefas que demandam mais esforços e mais comprometimento, uma forma de colaboração que as organizações têm adotado cada vez mais, devido à percepção de que o trabalho feito em grupo é desenvolvido mais eficazmente, especialmente no mundo globalizado, considerando que a equipe pode trabalhar remotamente apoiada por computador, via Web. Considera-se também que o trabalho em grupo apoiado por computador pode permitir uma comunicação mais rápida e sem horários fixos, o que potencialmente agiliza a realização das tarefas. Entretanto, percebe-se que nem sempre o trabalho colaborativo se torna efetivo, uma vez que os mesmos fatores anteriormente levantados como pontos positivos, podem também contribuir para a falta de motivação e o pouco engajamento dos membros da equipe, a pouca colaboração efetiva e a ausência de compromisso com os resultados. Outro aspecto a ser considerado é que essa equipe que trabalha de forma colaborativa via Web, geralmente está distribuída em diferentes locais, o que faz com que a cultura de cada um deles sejam diferentes, interferindo nos fatores motivacionais individuais. Baseado nesse contexto, este trabalho visa explorar a formalização de Patterns Motivacionais, mais especificamente Patterns Motivacionais baseados em cores. Para a formalização desses Patterns, será utilizada a base de conhecimento de Senso Comum, de forma a resgatar a cultura, valores e premissas de cada componente da equipe, a fim de motivá-los através das cores em seus trabalhos colaborativos em Projetos Web. LISTA DE ABREVIATURAS AA Ação de Aprendizagem AE Aprendizado Eletrônico API Application Programming Interface DC-UFSCar Departamento de Computação da Universidade Federal de São Carlos ES Engenharia de Software EuroPLoP European Pattern Languages of Programs GUI Grafical User Interface IHC Interação Humano-Computador ISO International Standards Organization LIA Laboratório de Interação Avançada MEC Ministério da Educação e Cultura MediaLab Media Laboratory MIT Massachusetts Institute of Technology OMCS Open Mind Common Sense OMCS-Br Open Mind Common Sense no Brasil OOPSLA International Conference on Object-Orientated Programming Systems, Languages and Applications. PLoP Pattern Languages of Program Design ÍNDICE Capítulo 1 - INTRODUÇÃO ................................................................................................. 8 1.1. Motivação ..................................................................................................................................... 8 1.2. Objetivos....................................................................................................................................... 9 1.3. Metodologia ................................................................................................................................ 10 1.4. Organização do Trabalho............................................................................................................ 11 Capítulo 2 - REVISÃO BIBLIOGRÁFICA .......................................................................... 13 2.1. Considerações Iniciais ................................................................................................................ 13 2.2. Patterns....................................................................................................................................... 13 2.2.1. Os Conceitos de Patterns de Alexander ............................................................................................... 15 2.2.1.1. Exemplo e Estrutura de um Pattern de Alexander .......................................................................... 16 2.2.2. Patterns de ES e de IHC ....................................................................................................................... 18 2.2.3. Patterns Organizacionais ...................................................................................................................... 21 2.2.4. Patterns Motivacionais ......................................................................................................................... 24 2.2.5. Formalização de Patterns ..................................................................................................................... 28 2.3. Cores na Web.............................................................................................................................. 32 2.3.1. Cores e seus significados ...................................................................................................................... 32 2.3.2. Contexto Web ....................................................................................................................................... 35 2.3.3. A questão das cores no Projeto Web..................................................................................................... 38 2.3.4. A metodologia de Aplicação de Cores .................................................................................................. 40 2.3.4.1. Briefing ........................................................................................................................................... 42 2.3.4.2. Os Esquemas de Combinações de Cores ........................................................................................ 42 2.3.4.3. As Cores de Contraste ..................................................................................................................... 44 2.3.4.4. As Relações entre a Cor e a Forma ................................................................................................. 45 2.3.4.5. A Simbologia das Cores na Cultura Ocidental................................................................................ 47 2.4. Senso Comum ............................................................................................................................. 49 2.4.1. Definição .............................................................................................................................................. 49 2.4.2. O Projeto OMCS-BR ............................................................................................................................ 50 2.4.2.1. A Arquitetura do Projeto ................................................................................................................. 50 1.4.2.1.1. O Site ....................................................................................................................................... 51 1.4.2.1.2. Módulo Gerador da ConceptNet .............................................................................................. 54 1.4.2.1.3. A ConceptNet .......................................................................................................................... 56 1.4.2.1.3.1. Redes Semânticas................................................................................................................ 56 1.4.2.1.3.2. Ontologias ........................................................................................................................... 57 1.4.2.1.4. A API ....................................................................................................................................... 58 1.4.2.2. Aplicações computacionais usando Senso Comum ................................................................. 59 1.4.3. Senso Comum e Cores expressando cultura – OMCS-Br ................................................................. 61 2.5. Considerações Finais .................................................................................................................. 62 Capítulo 3 - PROPOSTA DE TRABALHO ......................................................................... 64 3.1. Considerações Iniciais ................................................................................................................ 64 3.2. Justificativa Detalhada e Relevância do Trabalho ...................................................................... 64 3.3. Descrição do Trabalho ................................................................................................................ 65 3.4. Cronograma de Execução ........................................................................................................... 66 3.5. Resultados Esperados ................................................................................................................. 67 Referências Bibliográficas ............................................................................................... 68 ÍNDICE DE FIGURAS Figura 1: Pattern “Paving With Cracks Between the Stones” (Alexander et al., 1977) .................... 16 Figura 2: Funcionamento do processo motivacional (adaptado de Pontes et al.,2008) ..................... 24 Figura 3: Pattern “Intelligent Human” (Lukosch et al., 2007) ......................................................... 27 Figura 4: Círculo Cromático das Cores-Pigmento Transparentes (Silveira et al., 2005) .................. 40 Figura 5: Teoria da Percepção ........................................................................................................... 41 Figura 6: Estrutura da Metodologia de Aplicação de Cores no Projeto Web (Buchdid, 2006) ......... 42 Figura 7: Esquema básico acromático (I) e esquema básico neutro (II) ............................................ 43 Figura 8: Exemplo de Esquema dissonante ....................................................................................... 43 Figura 9: Exemplo de Esquema Consonante ..................................................................................... 44 Figura 10: Cores Pigmento Transparentes ......................................................................................... 44 Figura 11: Correlação entre as Cores e as Formas de acordo com Kandinsky (Buchdid, 2006)....... 46 Figura 12: Sinais da Cor (Gerstner, 1988) ......................................................................................... 46 Figura 13: Arquitetura do Projeto OMCS-Br .................................................................................... 51 Figura 14: Site do Projeto OMCS-Br ................................................................................................ 52 Figura 15: Exemplo de templates e processo de retro-alimentação do Projeto OMCS-Br................ 53 Figura 16: Interface do Sistema de Revisão das colaborações realizadas no site OMCS-Br ............ 53 Figura 17: Exemplo da Fase da extração ........................................................................................... 55 Figura 18: Exemplo da Fase da normalização ................................................................................... 55 Figura 19: Exemplo da Fase do relaxamento .................................................................................... 55 Figura 20: Exemplo de uma Rede Semântica. ................................................................................... 56 Figura 21: Exemplo de parte da ConceptNet do Projeto OMCS-Br .................................................. 56 Figura 22: Tipos de representação de ontologias (Yaguinuma, 2007; Uschold et al.,2004) ............. 57 Figura 23: Exemplo da interface da API utilizando a função “Navegar” .......................................... 58 Figura 24: PACO = Framework de Planejamento de Ações de Aprendizagem Apoiadas por Computador (Carvalho, 2007) ....................................................................................................... 59 Figura 25: Módulo do Jogador do jogo “O que é? O que é?” (Ferreira, 2007; Pereira, 2007) .......... 60 Figura 26: Cognitor = Framework Computacional para a Linguagem de Padrões CogLearn (Carlos, 2007) .............................................................................................................................................. 61 ÍNDICE DE TABELAS Tabela 1: Patterns desta Metalinguagem de Padrões de Meszaros para escrita de patterns (adaptada de Meszaros et al., 1996) ............................................................................................................... 29 Tabela 2: Tabela de Cores – OMCS-Br ............................................................................................. 33 Tabela 3: Metodologia para aplicação de cores baseada na Teoria da Percepção ............................. 41 Tabela 4: Cronograma de Execução .................................................................................................. 67 8 CAPÍTULO 1 - INTRODUÇÃO 1.1. Motivação Com a globalização e a necessidade de comunicação rápida sem locais e horários fixos, a Internet tem se tornado cada vez mais comum, tornando-se uma tendência que reforça o conceito de troca de informações e colaboração dos usuários com sites e serviços virtuais. Com isso, projetos Web estão cada vez mais sendo utilizados, sendo necessária uma maior preocupação quando são projetados. Sabe-se que os objetivos comuns dos projetos Web são as de motivar os usuários na utilização dessas aplicações, além de motivar as pessoas para o trabalho em grupo, cada vez mais apoiado por computador. Os desenvolvedores de tais aplicações devem procurar o que motiva os usuários e criar um ambiente que possibilite a satisfação individual de cada um deles, para que eles continuem trabalhando com suas aplicações e não as troque por outras. Para tal satisfação, uma das principais questões é a aplicação das Cores no projeto Web, devido ao fato de serem elementos para a comunicação visual, que podem reforçar ou não a intenção comunicativa e a interação do usuário com o sistema. As Cores podem ajudar os projetistas a destacar pontos importantes, bem como facilitar a leitura do conteúdo do site e, conseqüentemente, aumentar a satisfação do usuário. No contexto cultural, as cores devem ser consideradas como um fator diferencial na qualidade desses sistemas. Porém, tratar de cores em projetos Web é a garantia de um debate cheio de controvérsias e muita discussão, por ser um estudo complexo e basicamente interdisciplinar, extremamente ligado às questões culturais. É importante estudar e compreender quais são os valores agregados às cores, uma vez que esses valores são passíveis de interpretação e, portanto, podem variar de pessoa para pessoa, de cultura para cultura. Por essas razões, este trabalho propõe a formalização de Patterns Motivacionais para aplicações Web através das Cores, tanto para a equipe de projetistas como para os usuários dos sites, assumindo que os sites em questão visam estimular o trabalho colaborativo. Tal formalização será feita com o auxílio da base de conhecimento de senso comum do projeto OMCS-Br (Tsutsumi, 2006; Carvalho, 2007), considerando que patterns são entendidos como soluções de sucesso para um problema recorrente em um determinado contexto, conforme definição de Alexander (1977). 9 Os Patterns Motivacionais baseado em cores serão formalizados pensando no projetista Web e também nos usuários de Sites Web, em equipes de trabalho colaborativo apoiado por computador. E, sendo as cores um dos elementos de grande importância dentro de uma composição visual, suas potencialidades devem ser reconhecidas e utilizadas com a finalidade de possibilitar uma comunicação eficiente entre o sistema e o usuário, entre a equipe como um todo, trazendo estímulo reforçando a mensagem que se deseja passar para a equipe, considerando seu contexto e cultura. 1.2. Objetivos Este trabalho tem como principal objetivo a formalização de Patterns Motivacionais baseados em cores, que apóiem os diversos profissionais que atuam no desenvolvimento de sistemas Web, para que consigam além de gerar um projeto perceptivo e inserido esteticamente nos critérios de harmonia e comunicabilidade, motivar os usuários na utilização de tais sistemas Web considerando sua cultura, visando principalmente as equipes multidisciplinares que trabalham colaborativamente via Web, potencializando seu esforço e engajamento no trabalho. Para a criação de tais Patterns, conta-se com o apoio do conhecimento de Senso Comum, atualmente colhido através do Site Open Mind Common Sense no Brasil (http://www.sensocomum.ufscar.br) desenvolvido pelo LIA (Laboratório de Interação Avançada) do DC-UFSCar. A partir desses dados, será iniciada a análise dos mesmos utilizando-se a Metodologia de Aplicação de Cores criada por Silveira et al.(2005), formalizada por Buchdid (2006). Conseqüentemente à formalização dos Patterns Motivacionais, o objetivo secundário deste trabalho é oferecer uma linguagem comum entre os projetistas de sites de apoio ao trabalho colaborativo e os usuários integrantes da equipe que usa tais sites para desenvolver seu trabalho, a fim de facilitar a definição dos requisitos dos sistemas Web a serem projetados, tanto para motivar a equipe de trabalho colaborativo quanto para ajudar no desenvolvimento das soluções que eventualmente tais equipes venham desenvolver. Espera-se então colaborar efetivamente com os projetistas de interfaces no desenvolvimento de sistemas Web como ambientes colaborativos, através do uso de soluções comprovadas para os problemas recorrentes relacionados à motivação da equipe para o uso de sistemas Web para a colaboração, colhidas e formalizadas a partir de informações de Senso Comum sobre Cores de diferentes culturas. 10 1.3. Metodologia O projeto será desenvolvido pela mestranda, com o uso de equipamentos (microcomputadores, impressoras e ambiente de rede) disponíveis no LIA e softwares tanto de domínio público quanto os adquiridos pelo Departamento de Computação da UFSCar. A aluna deverá estudar os softwares, e familiarizar-se com o sistema computacional existente do projeto OMCS-BR. Além disso, continuando o estudo teórico que embasa o trabalho, a mestranda através de informações colhidas da base de conhecimento de senso comum do projeto OMCS-Br, deverá aplicar os princípios de formalização de patterns, especificamente patterns motivacionais e organizacionais, para a identificação e escrita dos patterns motivacionais baseados em cores. Intende-se também investigar uma correlação entre os patterns motivacionais a serem formalizados e os patterns organizacionais estudados, estabelecendo assim uma relação mais formal entre as áreas de IHC e ES para apoio a equipes multidisciplinares de desenvolvimento de sistemas Web. Esta pesquisa será realizada utilizando técnicas concernentes ao método científico, propostas para investigar um fenômeno e adquirir, ratificar ou integrar conhecimento. Esse método é baseado em evidências empíricas que podem ser observadas (Gauch Jr, 2002). Para a observação das evidências, será adotada a estratégia de pesquisa estudo de caso. De acordo com Yin (2002), estudo de caso é um tipo de investigação empírica que investiga um fenômeno inserido em um contexto da vida real. Ela pode incluir evidências qualitativas bem como evidências quantitativas para o desenvolvimento de proposições teóricas. Segundo Dias (2000), o estudo de caso consiste em uma investigação detalhada de uma ou mais organizações, ou grupos dentro de uma organização, com vistas a prover uma análise do contexto e dos processos envolvidos no fenômeno em estudo. O fenômeno não está isolado de seu contexto (como nas pesquisas de laboratório), já que o interesse do pesquisador é justamente essa relação entre o fenômeno e seu contexto. O autor salienta que o estudo de caso não é um método propriamente dito, mas uma estratégia de pesquisa. Neste trabalho adota-se a análise qualitativa dos dados obtidos através da realização do estudo de caso, pois levando em consideração a proposta deste trabalho, encontraram-se, na estratégia de estudo de caso, as ferramentas necessárias para conduzir a pesquisa, uma vez que se deseja observar num contexto da vida real, se o senso comum pode 11 apoiar efetivamente a formalização de patterns motivacionais. Para isso, serão realizadas análise e avaliação de usabilidade com projetistas de IHC e de ES, potenciais usuários desse tipo de pattern, bem como com usuários dos sistemas Web desenvolvidos com o apoio desses patterns. As análises serão baseadas nos critérios de usabilidade para esse tipo de solução, adotando métodos originados da Engenharia de Usabilidade de Nielsen (1993), como a Avaliação Heurística e Testes com Usuários. A escolha da análise qualitativa justifica-se, pois o trabalho se propõe identificar evidências que comprovem a utilidade do conhecimento de senso comum na formalização de patterns de IHC, especificamente os motivacionais. A análise qualitativa procura responder a questões de pesquisas por meio de organização, interpretação e categorização dos dados, com finalidade de adquirir conhecimento e dar significado a uma determinada experiência (Dias, 2000). Dessa maneira, considera-se que essas abordagens são adequadas ao alcance dos objetivos deste trabalho. Os resultados parciais serão analisados periodicamente em conjunto com a orientadora. Por fim, deseja-se também, fazer uma boa documentação do projeto, além de preparar artigos para sua divulgação em periódicos e congressos, como uma forma de análise dos resultados pelos pares 1.4. Organização do Trabalho Este trabalho encontra-se organizado da seguinte maneira: o Capítulo 2 apresenta a Revisão Bibliográfica realizada neste trabalho de mestrado, o qual está organizado em três principais seções: Patterns, Cores na Web e Senso Comum, explicada a seguir e, por fim, o Capítulo 3 apresenta a proposta de trabalho, com justificativas, relevâncias, objetivos, descrição, cronograma e os resultados esperados. Na revisão bibliográfica, a seção de Patterns aborda o conceito e um breve histórico de Patterns, enfatizando o trabalho de Christopher Alexander, o idealizador da idéia; também são apresentados os conceitos dos Patterns na área de ES e IHC; são relatadas a criação dos Patterns Organizacionais dentro da área de ES e os Patterns Motivacionais dentro da área de IHC. Por fim, são descritos os procedimentos de como realizar a formalização de Patterns. A seção Cores na Web apresenta a questão de definição e uso de Cores na Web, descrevendo as cores e seus respectivos significados; as cores no Contexto Web; e a contextualização da questão das cores no projeto Web e também é apresentada a metodologia 12 de Aplicação de Cores criada por Silveira et al.(2005) formalizada em Buchdid (2006), adotada neste trabalho. E a última seção do Capítulo 2 trata a questão do Senso Comum, que será utilizada para a criação dos Patterns Motivacionais de Cores, com uma definição do conceito de Senso Comum; a apresentação do projeto OMCS-Br e uma discussão sobre a utilização da base de conhecimento de senso comum. 13 CAPÍTULO 2 - REVISÃO BIBLIOGRÁFICA 2.1. Considerações Iniciais Este capítulo contém a Revisão Bibliográfica realizada para justificar e embasar a proposta de projeto a ser desenvolvido neste trabalho de mestrado. Para uma melhor compreensão, este capítulo está organizado em três principais seções. A Seção 2.2 apresenta o conceito de Patterns, um breve histórico, enfatizando o trabalho de Christopher Alexander, o idealizador da idéia; também são apresentados os conceitos dos Patterns na área de ES e IHC; são relatadas a criação dos Patterns Organizacionais dentro da área de ES e os Patterns Motivacionais dentro da área de IHC. Por fim, são descritos os procedimentos de como realizar a formalização de Patterns. A proposta deste trabalho é a criação de Patterns Motivacionais de cores para aplicações Web. Para isso, foi realizada uma pesquisa sobre cores na Web, para apoiar tal proposta. A segunda Seção 2.3 apresenta a questão de definição e uso de Cores na Web, descrevendo as cores e seus respectivos significados, as cores no Contexto Web, e a contextualização da questão das cores no projeto Web e também é apresentada a metodologia de Aplicação de Cores criada por Silveira et al.(2005), formalizada em Buchdid (2006), adotada neste trabalho. Adotou-se então a metodologia de Aplicação de Cores, a qual será utilizada para a formalização dos Patterns Motivacionais. Junto a essa metodologia, será utilizado o conhecimento de Senso Comum, que é expresso na cultura que as pessoas trazem com suas experiências, para a definição e compreensão da maneira com que as cores interferem e as motivam em seus cotidianos. Por fim, a Seção 2.4 trata a questão do Senso Comum, que será utilizada para a criação dos Patterns Motivacionais de Cores, com uma definição do conceito de Senso Comum; a apresentação do projeto OMCS-Br e uma discussão sobre a utilização de Senso Comum para expressar cultura com as cores, finalizando com algumas Considerações Finais. 2.2. Patterns Neste trabalho, optou-se em manter o termo Pattern em inglês, devido ao fato que em Português, a tradução deveria ser para o termo “Padrão”. Porém, esse termo já está associado a uma série de significados, tais como normas, padrões de comportamento, e 14 reconhecimento de padrões de sinais. Portanto, a manutenção do termo em Inglês ajuda não associar nenhum outro significado que o termo possa induzir, por isso, recomenda-se ao leitor entender o termo “Pattern” como um termo novo. Segundo Borchers (2001), os primeiros patterns foram escritos durante a época do Renascimento, por Francesco do Giorgio (1439-1501) que sistematicamente coletou, estruturou e documentou os conhecimentos arquiteturais de seus projetos na cidade de Siena. Porém, o conceito original de Patterns utilizados atualmente surgiu no final da década de 1970, concebido pelo arquiteto e urbanista Christopher Alexander, que escreveu sobre a aplicação de patterns ao design e à construção de cidades e edifícios. Para Alexander et al.(1977), pattern é a essência de uma solução de um problema recorrente em um certo contexto. Solução de um problema refere-se a cada pattern que identifica e descreve uma solução e o problema que tal solução resolve. Essência de uma solução são os elementos essenciais do pattern que são descritos, que deixa os aspectos específicos para geração pela pessoa que utiliza o pattern. Problema recorrente significa que o problema deve ter sido repetido diversas vezes de modo a viabilizar o esforço despendido para a descrição da solução. Finalmente, em um contexto valida e reconhece a solução em um contexto particular. Os patterns não estão isolados, mas conectados formando algo maior, conhecida como uma Linguagem de Padrões. Para Alexander et al.(1977), uma Linguagem de Padrões é a representação de um princípio repetitivo em um projeto de interação através de um conjunto de patterns estruturados hierarquicamente e inter-relacionados, criados para guiar o projetista pelos vários níveis de abstração através do processo. Segundo Borchers (2001), uma Linguagem de Padrões é um conjunto de patterns hierarquicamente estruturados que conduz o projetista a partir de assuntos de alto nível e abstratos para assuntos de projetos concretos e de pequena escala. Não há um consenso quando se trata de patterns, existem várias definições sobre o mesmo. Para Buschmann et al.(1996) da ES define pattern como sendo um par problema-solução em um determinado contexto, que apresenta a situação que dá origem ao problema. O problema é o conjunto de forças ocorridas repetidamente e a solução a maneira de resolver tais problemas. Enquanto isso, Coplien e Harrison (2005) também da Engenharia de Software, pattern é uma configuração estrutural recorrente que resolve um problema em um determinado contexto. 15 Uma outra definição para patterns, é apresentada por Borchers (2000) da IHC, que descreve que um pattern capta uma solução comprovada para um problema de projeto recorrente em uma forma de fácil entendimento, gerativa e compreensível às pessoas. Já Tidwell (1999) também da IHC define patterns como descrições para possíveis boas soluções para um problema comum de projeto em um certo contexto, descrevendo as qualidades invariáveis de todas as soluções. O termo “qualidades invariáveis” refere-se às características comuns e constantes ao analisar várias aplicações do pattern. Para obter uma definição englobando tanto os patterns de ES, quanto os de IHC, os patterns são entendidos neste trabalho como uma forma de expressar conhecimento através de textos e esboços em um formato estruturado, cuja solução proposta pelo pattern é de sucesso para um problema freqüente em um certo contexto. Á partir da definição de Patterns, Fincher (1999) define como características básicas: Formato de Apresentação; Captura de prática; Abstração; Princípio de Organização; Sistema de Valores; Facilidade de compreensão. Através dessas características, Fincher (1999) relata que patterns possuem dois benefícios: (I) Captar a experiência, pois patterns podem ser utilizados para a transferência de conhecimentos entre pessoas de níveis de experiência diferentes; (II) Fornecer um vocabulário comum, melhorando a comunicação entre a equipe de desenvolvimento e usuários leigos. Percebe-se que esses benefícios se encaixam na utilização de Patterns na área de ES e IHC, pois a motivação da aplicação por essas áreas difere. A ES aplica patterns com maior enfoque na troca de experiência entre os engenheiros de software enquanto a IHC enfoca mais em um meio de fornecer um vocabulário comum entre os especialistas e o usuário final do sistema. Essas diferenças serão melhores comentados e exemplificados na Seção 2.2.2. 2.2.1. Os Conceitos de Patterns de Alexander Para muitos autores como Fincher (2003), os aspectos mais importantes dos Patterns de Alexander são: • A intenção de fornecer um vocabulário comum entre os usuários leigos e arquitetos, e entre os próprios arquitetos; • A identificação por um princípio de invariância, e não criados ou inventados. Ou seja, Alexander percebeu que um problema era resolvido sempre da mesma maneira por diversos projetistas, com isso, identificou a solução de sucesso e formalizou o pattern; 16 • A estruturação de acordo com problemas já enfrentados por projetistas seguidos da solução que eles encontraram. Os 253 Patterns de Alexander foram combinados para formar uma Linguagem de Padrões, um tipo de gramática informal para edifícios e espaços. 2.2.1.1. Exemplo e Estrutura de um Pattern de Alexander Na Figura 1 é apresentado o Pattern “Pavimentar com Espaços Entre as Pedras” de Alexander et al.(1977) para exemplificar a estrutura de um pattern. Número 247 Ranking Nome Ilustração PAVIMENTAR COM ESPAÇOS ENTRE AS PEDRAS * * . . . muitos patterns precisam de caminhos e passagens que se ligam diretamente com a terra como em áreas ao ar livre ao redor de uma construção - Green Streets (51), Path Shape (121), Private Terrace on the Street (140), Outdoor Room (163), Connection to the Earth (168), Terraced Slope (169). Esse pattern fornece uma maneira de construir uma superfície que torne esses patterns mais harmoniosos. Contexto Três Asteriscos Asfalto e superfícies concretas ao ar livre são mais fáceis de lavar, no entanto eles não trazem nenhum beneficio para nós, para os caminhos, para a água das chuvas e plantas. Olhe um caminho simples, feito por tijolos ou pedras espaçadas e diretamente na terra. É bom para se caminhar, bom para as plantas, bom para a passagem de tempo, bom para a chuva. Você caminha de pedra em pedra, e sente a terra diretamente debaixo dos pés. Elas não racham, porque a terra preenche o espaço entre as pedras e essas se movem com a terra, assumindo gradualmente um caráter ricamente desigual. Com o passar do tempo, o caminho apresenta a mesma idade com uma leve desigualdade. Plantas, musgos e flores pequenas crescem entre os espaços. Os espaços também ajudam a conservar a delicada ecologia de minhocas, insetos, besouros e uma variedade de espécies de plantas. E quando chove, a água vai diretamente para o solo; não há nenhum perigo de erosão, nenhuma perda de água no solo ao longo do caminho. Declaração do Problema Descrição do Problema Todas essas são boas razões para se pavimentar com pedras. Passagens feitas de concreto e asfalto, não têm quase nenhum benefício. Elas são construídas quando as pessoas esquecem das pequenas vantagens trazidas pelas passagens pavimentadas com pedras espaçadas. Então: Em caminhos e passagens, pavimente com espaço de uma polegada entre as pedras, de forma que grama, musgos e flores pequenas possam crescer entre as pedras. Coloque as pedras diretamente na terra, e não use cimento entre elas. Solução Diagrama Três Asteriscos Pavimente com espaços, para auxiliar na criação de caminhos e passagens que ajudem as pessoas a sentir a terra debaixo dos seus pés – Connection to the Earth (168); as pedras são melhores se forem simples azulejos - Soft Tile and Brick (248). . . Figura 1: Pattern “Paving With Cracks Between the Stones” (Alexander et al., 1977) Referências 17 Um pattern de Alexander é definido estruturadamente da seguinte maneira: • Número: é o número do pattern dentro da Linguagem. • Nome: é o componente essencial, normalmente descreve o efeito de usar o pattern. É definido em poucas palavras e tem que ser fácil de lembrar e de referenciar quando o projeto for discutido. • Ranking: um valor indicando a confiabilidade do autor no pattern, no caso de Alexander, é composto de zero, um ou dois asteriscos. o Zero – significa que existem certamente outras maneiras de resolver o problema proposto. Assim são fornecidos mais de um exemplo, pois a solução de invariância ainda não foi encontrada. o Um – significa que o autor acredita que houve algum progresso no encontro da solução de invariância para esse pattern, mas o usuário é encorajado a usar outras soluções alternativas. o Dois – mostram que o autor acredita que descobriu a solução de invariância e que não existem maneiras melhores de resolver o problema declarado. • Ilustração: mostra um exemplo da aplicação do pattern. Geralmente é uma fotografia que ilustra boas idéias e o ambiente no qual o pattern é aplicado. • Contexto: é um parágrafo introdutório que mostra quais Patterns estão associados ao contexto do pattern em questão. Seu intuito é ajudar na aplicação do pattern, pois liga esse com outros Patterns de níveis mais altos dentro da escala hierárquica. • Três Asteriscos: mostram que o cabeçalho do pattern acabou e a parte central do pattern vai ser apresentada • Declaração do Problema: é um resumo que mostra a situação geral proposto pelo autor do pattern, em outras palavras, é um encapsulamento do problema que resulta em uma ou duas orações. Sempre é destacado em negrito. • Descrição do Problema: é o corpo do pattern e pode conter muitos parágrafos longos. Mostra o estado do problema e usa o conceito de competir forças. As forças são os vários motivos que o usuário tem para utilizar ou não o pattern naquele contexto, ou seja, elas expressam argumentos ou interesses conflitantes. • Solução: é considerada o coração do pattern e é sempre exposta na forma de uma instrução. Mostra a partir de exemplos, a solução geral para o problema de forma clara. 18 No entanto é genérica, de tal maneira que possa ser aplicada em situações variadas de acordo com o gosto de projetista. Sempre aparece em negrito. • Diagrama: é a essência da solução apresentada de uma forma visual através de um esboço que é fácil de assimilar e relembrar. • Três Asteriscos: enfatizam que a parte central do pattern acabou e a parte final vai começar. • Referências: é o parágrafo final, mostra como esse pattern se ajusta aos outros Patterns, situados em níveis inferiores da hierarquia da Linguagem. Nos patterns de Alexander, embora sejam apresentados os componentes citados anteriormente, os nomes desses componentes não aparecem no texto do pattern. Então, Alexander preferiu diferenciar as partes dos seus patterns através de uma apresentação tipográfica diferente. O nome do pattern é apresentado em letras maiúsculas, o problema e a solução estão em negrito e em parágrafos separados, os diagramas são apresentados através de esboços feitos à mão, o contexto começa com “...” e as referências são finalizadas por “...”, a solução é introduzida com a palavra “Therefore:” (traduzido para o Português como “Então:”) em uma linha separada, entre outras representações utilizadas (Silva, 2005). Segundo Borchers (2001), o objetivo de Alexander ao utilizar essa tipografia, seria a de não distrair o leitor em caso de palavras repetitivas. Com o seu trabalho sobre patterns, Alexander et al. (1977) além de incentivar o uso de patterns em outras áreas, foi também utilizado como exemplo, devido à maturidade de seu trabalho. Porém, suas idéias não foram bem aceitas por outros arquitetos e o motivo para tal, foi o aumento do poder de decisão dos habitantes no projeto, retirando assim o poder dos profissionais (Borchers, 2000). 2.2.2. Patterns de ES e de IHC O objetivo de Alexander na publicação de sua Linguagem de Padrões era permitir aos usuários leigos, os habitantes, a capacidade de projetar seus próprios ambientes. Essa preocupação é similar às idéias encontradas em Engenharia de Software, no Projeto Centrado no Usuário, e no Design Participativo cujo objetivo é envolver usuários finais em todos os estágios do ciclo de desenvolvimento de software (Borchers 2001). O primeiro uso de patterns de ES, foi em 1987 com um experimento cujo relatório foi publicado na International Conference on Object-Orientated Programming Systems, Languages and Applications (OOPSLA), onde Beck e Cunningham (Borchers, 19 2001), se basearam na idéia de Alexander e criaram uma Linguagem de Padrões simples, composta por cinco patterns, que abrange as regras para o projeto da interface com o usuário para aplicações em Smalltalk. Para Borchers (2000), essa idéia que abordou os conceitos de Design Participativo, foi a razão mais importante para levar a comunidade de ES a adotar a idéia de Patterns. Em 1995, Gamma et al.(1995), publicaram uma Linguagem de Padrões para projeto de software orientado a objeto na conferência anual Pattern Languages of Programming (PLoP). Este trabalho intitulado como Design Patterns: Elements of Reusable Object-Oriented Software, conhecido como GoF - Gang of Four, forneceu aos engenheiros de software experientes uma forma mais prática de transferir suas experiências adquiridas em projetos anteriores entre eles e também com desenvolvedores menos experientes. Entre 1987 a 1997 poucos patterns da área de IHC foram divulgados pela comunidade científica, ao contrário da área de ES. Após esse período, alguns pesquisadores começaram a apresentar resultados de seus trabalhos com patterns de IHC. Entre esses pesquisadores pode-se citar Jennifer Tidwell, Jan Borchers, Martijn van Welie e Francisco Montero pelos avanços nessa área. A preocupação desses pesquisadores da área de IHC não estava enfocada somente na descoberta de novos patterns e montagem de Linguagem de Padrões, mas no esforço da comunidade em aproximar a qualidade do trabalho que estava sendo realizado com os patterns na área de IHC com a qualidade do trabalho de Alexander na Arquitetura (Silva, 2005). Tidwell (1999) apresentou vários patterns, que foram organizados em uma Linguagem de Padrões, chamada de Commond Ground, que apresenta patterns para o projeto de interação entre humanos e qualquer tipo de artefato, podendo ser físico como um livro ou digital como um software e uma Coleção de Padrões (quando a formatação dos patterns não é uniforme no decorrer do trabalho) voltada especificamente para a construção de interfaces com o usuário (Talarico Neto et al., 2004). Já os patterns de Borchers (2001) estão relacionados à como representar o modelo mental do usuário e como tornar a interação mais atrativa aos usuários em sistemas interativos. Welie et al.(2003) apresentam diversos patterns para a Web, para interfaces GUI (Grafical User Interface) e para interfaces de sistemas em móbeis. Além de identificar 20 patterns, Welie também realiza pesquisas relacionadas a classificações de patterns de IHC e o uso de ferramentas para apoiar a escrita e o uso de patterns. Montero et al. (2002) apresentam em seu trabalho uma Linguagem de Padrões para projeto de websites. Nos últimos anos, a comunidade de IHC começou a desenvolver interesses por patterns. Vários autores retornam às intenções originais de Alexander para facilitar a participação do usuário (Löwgren, 2005). As metas dos patterns de IHC são compartilhar soluções de sucesso entre os profissionais de IHC, além de prover um idioma comum para as pessoas envolvidas em qualquer parte do projeto, desenvolvimento, avaliação ou uso interativo dos sistemas (Borchers et al.,2001). Não existe ainda uma classificação exata e amplamente aceita entre os pesquisadores de patterns na ES. Rihle e Züllighoven (1996) dividem os patterns de ES nas seguintes categorias: Patterns Conceituais, Patterns de Projeto e Patterns de Programação. Existem outras classificações, como por exemplo, a de Buchmann et al.(1996) onde apresentam uma classificação segundo as fases propostas pela ES, dividindo os patterns em: Patterns Organizacionais, Patterns de Análise, Patterns de Projeto que por sua vez se dividem em Patterns Arquiteturais, de Projeto e Idiomas. Os Patterns Organizacionais são propostos por Coplien et al. (1995), descrevem estruturas e práticas das organizações humanas. São também voltados para o suporte organizacional e técnicas de processos para o desenvolvimento de software. Esses patterns serão tratados com mais detalhes na Subseção 2.2.3. Assim como os Patterns de ES, não existe uma classificação amplamente aceita e difundida dos Patterns de IHC (Buchmann et al.,1996). Mahemoff e Johnston (1998) apresentam categorias para patterns de IHC composto por quatro categorias: tarefas, usuários, elementos da interface com o usuário, e sistemas inteiros. Segundo os autores dessa classificação, patterns de tarefas fornecem detalhes de alto nível das tarefas que os usuários freqüentemente realizam e como eles podem ser suportados pelo sistema. Os patterns de usuários auxiliam o analista garantindo que o sistema suporte diferentes tipos de usuário, dependendo do contexto, enquanto que os patterns de elementos da interface com o usuário detalham o uso apropriado de um widget. A última categoria é composta por patterns que capturam questões relativas a todo o sistema, e são chamados de patterns para sistemas inteiros, lidando com a forma de interação, como manipulação direta, menus e formulários. 21 Existe também uma classificação de patterns de IHC definida por Alpert (2003): Patterns de IHC, Patterns de interface com o usuário e Patterns para Avaliação de Usabilidade. • Os patterns de IHC estão relacionados com preocupações de alto nível, e algumas vezes com guidelines (são objetivos mais específicos refinados por especialistas em IHC a partir da pesquisa dos princípios para diferentes contextos), envolvendo a psicologia do usuário. • Os patterns de interface com o usuário são mais relacionados a problemas de interação específicos e sua solução é baseada em componentes de interface com o usuário. • Os patterns de avaliação de usabilidade expressam como conduzir o processo de avaliação de usabilidade, auxiliar a planejar e executar a avaliação e editar e avaliar os dados coletados. Dentro dos patterns de IHC, encontram-se os Patterns Motivacionais, que define como as pessoas se engajam na organização, os quais serão tratados com mais detalhes na Subseção 2.2.4. 2.2.3. Patterns Organizacionais James Coplien e Douglas Schmidt (1995) apresentaram diversos Patterns na conferência PLoP em 1995. Na PLoP, Coplien alertou para a falta de especificação de Patterns em diversas áreas ainda inexploradas e também abordou a questão de Patterns em organizações e processos (Process and Organization Patterns), comentando que o estudo de processos e organizações já estão em estágio maduro, entretanto, a forma de Patterns para a descrição desses processos ainda é um tema de pesquisa (Quináia, 2005). Os patterns organizacionais e de processo cobrem problemas de desenvolvimento de software. Eles podem ser usados para modelar uma nova organização e seu processo de desenvolvimento. Assim, a proposta de Coplien et al.(1995) é que a integração dos patterns organizacionais e de processo possibilita o desenvolvimento de software mais rapidamente e com qualidade. Coplien e Schmidt (1995) apresentam um modelo de seis partes para a descrição de um pattern: • Problema: descreve o problema a ser resolvido pelo pattern; • Contexto: descreve o contexto no qual a solução descrita resolve o problema; 22 • Forças: são considerações contraditórias e devem apontar para a escolha da solução daquele problema, ajudam a orientar em determinar se é aplicável à situação do leitor; • Solução: descreve a solução do problema já descrito; • Contexto resultante: descreve o resultado esperado após a aplicação da instância da solução proposta; • Raciocínio: descreve o porquê e dá exemplos que justificam a solução. Após o surgimento da linguagem de Patterns Organizacionais e de Processo de Coplien e Schmidt (1995), surgiram várias outras linguagens para apoiar e organizar a construção do software, como as propostas por Coplien e Harrison (2005), que combinam estruturas organizacionais com as melhores práticas de desenvolvimento de software, que podem ser utilizados para estabelecer estruturas organizacionais e práticas cujo objetivo é melhorar o processo de desenvolvimento de software da organização. Essas linguagens devem ser usadas em conjunto para solucionar os problemas da organização e fortalecê-las. Elas foram desenvolvidas através de um esforço coletivo na pesquisa sobre patterns organizacionais e de processo. São elas: • Linguagem de Padrões de Gerenciamento de Projeto: trata da construção do trabalho na organização, concentrando-se no cronograma, processo, tarefas e em estruturas para apoiar o progresso do trabalho. • Linguagem de Padrões de Desenvolvimento Gradativo: descreve como criar a organização e o processo ao mesmo tempo. • Linguagem de Padrões de Estilo Organizacional: trata da estrutura de relacionamentos dos papéis na organização. • Linguagem de Padrões de Pessoas e Código: trata do relacionamento entre a estrutura da organização e os artefatos que são construídos. Um exemplo de pattern organizacional e de processo da linguagem de Coplien e Harrison (2005), é o Fire Walls (Corta Fogo), cuja forma de apresentação é a de Alexander (conhecida como forma Alexandrina), que é apresentado a seguir: 1) Nome: Fire Walls ** (Os asteriscos ao lado do nome do pattern representam a confiança no pattern e variam de zero a dois). 23 2) Contexto: uma organização de desenvolvedores é formada em um contexto corporativo ou social, em que esses são freqüentemente distraídos por pessoas externas que sentem necessidade de oferecer informações e fazer críticas. 3) Resumo do Problema: é importante proteger os desenvolvedores de outras pessoas envolvidas no projeto, que não participam do desenvolvimento, mas querem ajudar por meio de comentários ou críticas. 4) Problema detalhado: o isolamento não funciona: o fluxo da informação é importante. Mas, o excesso de comunicação aumenta de forma não linear em relação ao número de colaboradores externos. 5) Solução: crie um cargo de gerente, que proteja os desenvolvedores de interações com cargos externos, para evitar interrupções durante o desenvolvimento. 6) Contexto Resultante: a nova organização isola os desenvolvedores de interrupções externas que não são relevantes. Para evitar o isolamento, esse pattern deve ser utilizado em conjunto com outros, como Engage Customers (Envolver o Cliente) e Gate Keeper (Porteiro). 7) Análise Racional: o pattern Fire Walls restringe o fluxo de informações. O pattern Gate Keeper facilita o fluxo de informações úteis. É necessário balancear esses dois patterns. O pattern Fire Walls fornece uma solução para um problema pertinente às organizações que desenvolvem software: o excesso de solicitações e informações desnecessárias que são passadas aos desenvolvedores. Sabe-se que essas interrupções afetam diretamente a produtividade. Portanto, o pattern Fire Walls deve ser utilizado para manter os desenvolvedores concentrados em suas tarefas, pois a comunicação em excesso pode sobrecarregar o projeto. Os pattern organizacionais e de processo não aparecem de forma isolada, mas na forma de Linguagem de Padrões, embora possam ser aplicados de forma individual. São várias as Linguagens de Padrões organizacionais e de processo disponíveis na literatura. Porém, somente alguns serão utilizados neste trabalho, que serão integrados aos Patterns Motivacionais. 24 2.2.4. Patterns Motivacionais Motivação refere-se aos desejos, aspirações e necessidades que influenciam a escolha de alternativas, determinando o comportamento do indivíduo. Pode-se então, dizer que a motivação consiste nos seguintes elementos (Pontes et al.,2008): 1. Todo indivíduo tem necessidades, as quais variam em intensidade e persistência. 2. Satisfazer essas necessidades é o objetivo para o qual a motivação é dirigida. 3. Quando o objetivo é definido, isso é traduzido em desejo, transformando-se em produtividade. 4. A atividade proposta resulta da aplicação de um incentivo ou estímulo para atingir o objetivo. 5. O comportamento é a maneira com que o indivíduo se comporta mediante suas necessidades, vindas de necessidades internas e estímulos externos. Trazendo essa definição para uma forma gráfica, tem-se a Figura 2, que esquematiza o funcionamento do processo motivacional. 1 Motivos Necessidades Interno 4 Incentivo Estímulo 2 5 Comportamento Satisfação 3 Objetivo Produtividade Externo Figura 2: Funcionamento do processo motivacional (adaptado de Pontes et al.,2008) O termo motivação do ponto de vista do indivíduo é um estado interno que conduz à busca de objetivos. A motivação pessoal afeta a iniciativa, a direção, a intensidade e a persistência de esforço. Segundo Donner (2008), uma pessoa motivada segue em frente, concentra os esforços na direção correta, trabalha com intensidade e mantém o esforço. As pessoas são motivadas para preencher necessidades que no momento não estão satisfeitas. Existem dois passos básicos nas motivações das pessoas (Pontes et al.,2008): 25 1) É preciso saber o que as pessoas desejam, que necessidades elas estão tentando satisfazer. Para conseguir tais respostas, é preciso perguntar diretamente ou observar a pessoa. Podese também obter essas informações indiretamente, se tentar conhecer melhor cada pessoa. 2) É preciso dar a cada pessoa a chance de satisfazer necessidades no trabalho. Para exemplificar, uma maneira de motivar uma pessoa com uma forte necessidade de autonomia é permitir que ela trabalhe independentemente. Neste trabalho, a proposta é que a motivação seja trabalhada através do estímulo das cores. No contexto de aplicação Web, pretende-se investigar o significado das cores em termos cultural para as pessoas de maneira geral, a fim de perceber como prover o estímulo adequado aos visitantes de sites Web, considerando seus objetivos e qual a motivação desejada para tais usuários. Adota-se o esquema da Figura 2, com o objetivo de formalizar Patterns Motivacionais baseados em cores. Para que isso possa ser realizado, é apresentado aqui um estudo inicial sobre Patterns Motivacionais. Uma das Linguagens de Padrões estudada foi a de Till Schümmer e Stephan Lukosch (2007a), conhecida como Patterns for Computer-Mediated Interaction. Essa linguagem visa projetar aplicações modernas, onde muitas pessoas colaboram com pontos remotos pela Internet, como: Jogos de vários jogadores, Sites da Web que fazem interação entre visitas, Aplicações para interação entre usuários móveis, Sistemas que nutrem aprendizagem colaborativa, entre outros. Além dessa linguagem, Till Schümmer e Peter Tandler (2007b) também criaram a Linguagem de Padrões Patterns for Technology Enhanced Meetings, que contém 20 patterns que esclarecem como fazer o uso da tecnologia quando preparar e administrar uma reunião, visando a motivação em reuniões. De acordo com Schümmer et al. (2007b) esses patterns foram desenvolvidos através de práticas sociais de boas reuniões e implicações para apoio à adoção da tecnologia em reuniões. São ilustrados em três áreas de aplicações diferentes: reuniões em contextos comerciais, reuniões no contexto de aprendizagem de grupo e reuniões no contexto de comitês em organizações governamentais. Lukosch et al.(2007) apresentaram ao EuroPlop seis Patterns Motivacionais para tornar um sistema colaborativo mais eficiente. Na Figura 3 é apresentado o pattern “Ser humano Inteligente” de Lukosch et al.(2007) para exemplificar a estrutura de um Pattern Motivacional. 26 Nome Intelligent Human Nomes Alternativos (Turing Test, Human Interaction Proof) Distinguir entre respostas automatizadas e um usuário real enviandolhe um desafio intelectual. Está se criando um sistema que é usado pelos seres humanos. Intenção Contexto Três Asteriscos Interação mediada por computador não permite o usuário local se certificar se o usuário de um site distribuído é real. Problema John está viajando com o seu cachorro para um agradável Hotel em Las Vegas. Esse hotel tem muitos serviços entre outros uma máquina central de TV que pode ser controlada por uma unidade de controle remoto. Infelizmente, John deixou o cachorro no quarto do hotel e o cachorro caminhou para o lado contrário do controle Cenário remoto, ativando uma fenda da máquina virtual. Depois que John retornou, o cachorro dele havia gasto 500$. Deve-se considerar a aplicação do pattern quando... • Os usuários querem compartilhar informações com usuários semelhantes, mas eles não querem que suas informações sejam usadas abusivamente por serviços automatizados como correspondentes de spam. • Assume-se que o usuário tem um nível intelectual específico, que ele pode ler e entender um texto específico. Descrição do Problema Outros usuários usam de forma abusiva do seu sistema criando automaticamente muitas contas e assim usam mais recursos do que eles deveriam levar. Então: • Faça ao usuário uma pergunta que é difícil de responder para computadores antes de se permitir que o usuário prossiga em sua ação. Solução O usuário pede um serviço específico do sistema. Antes de o serviço ser processado, o sistema envia um desafio ao usuário. Um exemplo de um desafio é o reconhecimento um texto gráfico, uma imagem ou texto falado. O usuário digita então uma resposta para o desafio e o sistema verifica se a resposta está correta. Se a resposta for correta, o sistema completa o serviço requerido. Do contrário, ele envia um novo desafio. Assegure-se que o desafio é fácil de criar pelo computador, mas difícil de resolver. Portanto, inclua um fator randômico que distorça a informação da solução de uma maneira que o computador falhe ou não reconheça o algoritmo. Colaborações Níveis diferentes de distorção de textos. A Figura acima mostra como um texto é distorcido se tornar menos legível pelo programa do computador. Enquanto o texto original (1ª Parte da Figura) é fácil de reconhecer por um algoritmo de reconhecimento de caractere óptico, o segundo exemplo é mais difícil já que ele adiciona umas distorções periódicas (com um período randômico maior). A última imagem é ainda mais difícil de reconhecer devido à inclusão de ruídos. 27 A suposição básica desse pattern é que humanos são ainda melhores em informações agrupadas ou reconhecíveis do que computadores em casos onde o algoritmo de reconhecimento é desconhecido ou tem um parâmetro Raciocínio randômico. No caso de reconhecimento de caractere, é fácil para humanos detectarem as formas bem conhecidas dos caracteres mesmo quando as formas estão distorcidas. Um exemplo bastante conhecido da vida real é o reconhecimento da escrita cursiva. Enquanto isso ainda é difícil para computadores, não é um grande problema para humanos. O mesmo é verdade para o reconhecimento de voz onde a maioria dos usuários é capaz de filtrar uma voz específica a partir de um conjunto de sons. Com isso, conclui-se que o usuário humano poderá passar no desafio enquanto um programa de computador será bloqueado. Quando se aplica esse pattern, deve-se responder a essas questões: • Como se desafiará o usuário? Confiar-se-á nas habilidades de reconhecimento de uma imagem ou usar-se-á capacidades de reconhecimento de voz? • Como você controla usuários que não são capazes de executar o desafio (por exemplo: pessoas com necessidades especiais)? Checar Os programas podem se tornar muito sofisticados que como resultado, eles são hábeis para resolver o quebracabeça. No caso de uma imagem distorcida poder ser reconhecida o programa pode, por exemplo, especializar-se em reconstruir a imagem original e então reconhecer os dados distorcidos. Isso significa que o nível de distorção precisa ser acrescido. No entanto, um nível de distorção pode conduzir a um segundo importante ponto de perigo Pontos de Perigo do pattern: O usuário humano pode não ser capaz de resolver o quebra-cabeça. Nesse caso, deve-se assegurar o oferecimento de um quebra-cabeça alternativo. Se pedir ao usuário que reconheça um conjunto distorcido de caracteres, você poderia prover um arquivo em áudio, onde os caracteres são lidos. Reconhecimento de imagem: Mais e mais sites Web apresentam ao usuário imagens distorcidas por um texto randômico. Ao interagir, o usuário primeiramente tem que reconhecer o texto e colocá-lo no sistema. Se o texto estiver correto, o sistema assume que o usuário é real. As contas do Google pedem que o usuário reconheça e digite o texto. Endereço de e-mail para páginas Web: Nos primórdios da Web, era uma prática comum incluir uma referência do Usos conhecidos autor da página na página como um link que ao clicar abria o programa de correio eletrônico do usuário com o destinatário já incluso. No entanto, esses links passaram a ser scaneados por web crawlers (robôs web), que são pequenos programas de software que visitavam páginas Web e buscavam na página informações úteis, como no caso, endereço de e-mail. Os endereços de e-mail eram coletados por um crawler e vendidos para mass mailers (empresas interessadas em enviar e-mail’s em massa). Como resultado, o autor recebe mais e mais Spams. Portanto, hoje em dia, o link do e-mail é freqüentemente usado com um endereço de e-mail transcrito, por exemplo: james(at)schuemmer(dot)de enquanto o endereço deveria ser [email protected] clicar sobre o link, o agente de e-mail ainda abre um novo e-mail, mas agora com um endereço inválido que o usuário como um Intelligent Human pode corrigir manualmente antes de enviar o e-mail. Caso contrário, a interação não é possível. Três Asteriscos Intelligent Human deveria ser aplicado durante um Quick Registration nos sistemas baseados em Web tal que os crawlers não possam preencher formulários quando vistoriando a Web. Figura 3: Pattern “Intelligent Human” (Lukosch et al., 2007) Patterns Relacionados 28 Para este trabalho em questão, alguns estudos estão sendo realizados como os de Schümmer et al.(2007a; 2007b), Lukosch et al.(2007) já citados, além de outros como: Motivational Patterns in Virtual Team Collaboration (Clear et al., 2005), Inspirational Patterns for embodied interaction (Löwgren, 2005), a fim de colher características que possam ser úteis na criação dos Patterns Motivacionais baseado em cores para o projeto Web. 2.2.5. Formalização de Patterns Atualmente, as principais conferências sobre patterns são (Salviano, 1997): • PLoP: realizadas anualmente, desde 1994, em Monticello, Illinois, EUA, no mês de setembro. • EuroPLoP: realizadas anualmente, desde 1995, na Alemanha. • OOPSLA: realizada anualmente, desde 1986, nos Estados Unidos. Apesar de ser dirigida a orientação a objetos, diversos artigos, tutoriais e workshops em patterns, relacionados ou não a objetos, foram apresentados nas últimas realizações desta conferência. Essas conferências estabelecem alguns critérios que devem constar nos patterns submetidos à avaliação na conferência, como por exemplo, que os patterns devem descrever soluções comprovadas para soluções recorrentes, e que o autor do pattern não precisa ser o inventor da solução documentada. Enfim, nessas conferências, os patterns são discutidos em workshops, procurando sugerir melhorias ao autor, que pode incorporá-las ao pattern antes que apresentem sua forma final. Meszaros e Doble (1996), preocupados em ajudar o desenvolvimento de patterns, elaboraram uma metalinguagem, que é uma linguagem para se escrever patterns, baseados na experiência dos revisores do PLoP. Apesar da metalinguagem ser estruturada tendo em vista vários elementos, Meszaros e Doble (1996) relatam que algumas dessas informações não são necessárias para todos os patterns. No entanto, existe um conjunto essencial de informação necessário para que o pattern possa ser aplicado. Para Meszaros e Doble (1996), além da estrutura de cada pattern o autor deve se preocupar com características como: a Linguagem de Padrões deve “dividir e conquistar”, reduzindo problemas grandes em problemas pequenos. Captar cada par “problema/solução” de modo que cada patterns possa ser usado sozinho ou com um número limitado de patterns. 29 Cada pattern deve resolver um problema específico dentro do contexto da Linguagem. Os patterns devem ter nomes evocativos, fáceis de recordar e de referenciar. Devem descrever problemas gerais, e mostrar de forma resumida como os patterns podem trabalhar juntos para resolver esse problema. Também precisam usar referências legíveis para relacionar outros patterns, que devem estar presentes na descrição do pattern, especialmente no Contexto de forma relacionada. A Tabela 1 apresentada abaixo é um resumo dos patterns desta Metalinguagem (Meszaros et al.,1996), que podem ser usados como referência na criação de patterns. Tabela 1: Patterns desta Metalinguagem de Padrões de Meszaros para escrita de patterns (adaptada de Meszaros et al., 1996) Problema Como se tem certeza de que toda a informação necessária está descrita em um pattern? Como ajustar informação essencial, mas que não se ajusta bem nos Elementos Obrigatórios? Como assegurar que o leitor entende a escolha da solução? Como fazer com que a essência de uma solução seja adquirida de forma rápida? Como minimizar a quantidade de leitura para que o usuário adquira a essência de um pattern? Solução Inclua os seguintes elementos: Nome do Problema, Problema, Solução, Contexto, Forças. Inclua os seguintes elementos para inserir tais informações essenciais: Contexto Relacionados, Resultante, Patterns Exemplos, Exemplos de Código, Razão e Pseudônimo. Independente do estilo escolhido para descrever o pattern, garanta que as forças estejam bem destacadas. Escreva o pattern de forma que não seja necessária a leitura posterior para entender as partes iniciais. Claramente identifique o Problema, Contexto e Solução separadamente, de forma que o leitor identifique rapidamente se este pattern aplica-se a ele. Nome do Pattern Elementos Presentes Obrigatórios Elementos Opcionais quando necessários Forças Visíveis Leitura passada em uma Seções Dispensáveis Percebe-se que escrever Patterns é uma atividade muito dispendiosa (Buchdid, 2005). Por esse motivo, Vlissides (1996) propõe sete hábitos que foram adotados durante a escrita de quatro anos do livro Design Patterns de forma inconsciente, para facilitar o desenvolvimento de uma Linguagem de Padrões de boa qualidade. São eles: 1) Tempo para Refletir - é a atividade de maior importância na escrita de Patterns, pois leva tempo para registrar experiências, como: pensar no desenvolvimento dos sistemas, nos problemas enfrentados, nas soluções adotadas (ou não adotadas). As experiências são a matéria prima dos Patterns e são acumuladas quando observamos um número grande de sistemas projetados por outras pessoas. 30 2) Escolher uma Estrutura - é escolher uma estrutura para escrever o conjunto de Patterns. Uma vez escolhida, ela deve ser aplicada em todos os patterns. Isso dará aos patterns uma linguagem comum que facilita a busca por informações dentro da estrutura hierárquica da Linguagem e os tornam mais fáceis de ser comparados pelos leitores. Quanto menos estruturado, ou seja, mais narrativo, será mais fácil realizar a leitura, porem não é adequado para comparações e propósitos de referência. Uma vez escolhida a estrutura, ela deve ser seguida. Caso seja necessário mudar a estrutura, uma vez que os patterns estiverem mais amadurecidos, será necessário realizar a modificação em todos os outros patterns já definidos. 3) Ser Concreto – é apresentar os conceitos de forma concreta, mesmo quando for abstrato. Mostrar exemplos do mundo-real, contra-exemplos e ilustrações ao longo do pattern para enfatizar pontos chaves. Também é importante advertir o leitor sobre armadilhas potenciais do pattern, pois nenhum pattern está livre de desvantagem. Essas desvantagens têm que ser evidenciadas antes que os usuários usem os patterns de uma forma incorreta. 4) Identificar Patterns Distintos e Complementares – se dois patterns resolvem os mesmos ou semelhantes problemas, é provável que os mesmos possam ser fundidos, caso contrário é importante manter documentos separados com suas diferenças. Esse hábito enfatiza que, ao escrever um pattern, um autor esquece sobre outros patterns ou tem dificuldades de explicar como os patterns interagem coletivamente. 5) Apresentar de Forma Clara – é escrever o pattern da melhor forma possível. Não adianta descobrir o melhor pattern do mundo e não conseguir apresentá-lo de forma clara, de modo que outras pessoas não possam entender o que foi escrito. Tenha certeza de que tudo que se escreve pode ser dito a um amigo, ou seja: evitar a voz passiva, separar orações longas e parágrafos, além de usar palavras cotidianas de uma maneira que soe natural. 6) Interagir Incansavelmente – é a necessidade de escrever e reescrever os patterns muitas vezes. Uma mudança insignificante em um pattern pode causar um grande impacto, pois os patterns não existem isoladamente; eles afetam um ao outro. 7) Colecionar e Incorporar o Feedback - é a importância de deixar que outras pessoas leiam, entendam, e comentem seus patterns, porque nenhum pattern é de confiança até que seja usado por alguém além do autor. Normalmente, patterns são perfeitamente compreensíveis às pessoas que estão familiarizadas com o problema, pois eles usam esses 31 patterns inconscientemente. Assim, os patterns têm que ser compreensíveis para as pessoas que nunca se defrontaram com o problema. Resumidamente, os patterns necessitam ser anotados, testados, e gradativamente melhorados. Segundo Vlissides (1996), esses sete hábitos não garantirão o sucesso na criação do pattern, mas podem ser utilizados de forma a ajudar a enfocar os esforços de forma construtiva. Sabe-se que para a formalização de Patterns, há duas maneiras: através de observação ou através de consulta a um especialista da área. No caso deste trabalho, para a formalização dos Patterns Motivacionais será utilizada as duas maneiras: através do uso da Metodologia das Cores, criada pela especialista em cores Luciana Martha Silveira (Silveira et al.,2005), formalizada em Buchdid (2006), apresentada na Seção 2.3, e também adotando-se a Linguagem de Meszaros et al.(1996) já citada a partir da observação da necessidade das pessoas em relação às suas motivações. Nesta Seção foram apresentados conceitos de patterns, desde sua idéia original, com Alexander, até a área de pesquisa Patterns Organizacionais e Motivacionais, que envolve diretamente as áreas de IHC para aplicações Web. Também foram mostrados exemplos para enfatizar o conceito e as dificuldades de se construir em Pattern uma Linguagem de Padrões. A formalização de Patterns em IHC tem um grau de complexidade elevado, pois envolve conceitos interdisciplinares que se estendem desde questões individuais, passam por requisitos de usabilidade e chegam até as questões culturais, que juntas resultam na qualidade do sistema projetado. Os Patterns Motivacionais serão explorados de forma a motivar os usuários na utilização de Sistemas Web, especificamente relacionados à aplicação de cores, pois no projeto, de alguma maneira as cores estão sempre presentes na maioria dos sistemas, contribuindo para o sucesso dos mesmos. 32 2.3. Cores na Web De acordo com Silveira (2002), falar sobre Cores é a garantia de um debate cheio de controvérsias e muita discussão, por ser um estudo complexo e basicamente interdisciplinar. Para o projetista Web, é importante estudar e compreender quais são os valores agregados às cores, uma vez que esses valores são passíveis de interpretação e, portanto, podem variar de pessoa para pessoa, como será comentado nas próximas seções. A princípio, as cores no projeto Web, não são os únicos elementos para a comunicação visual, mas elas são um dos elementos que podem reforçar ou destruir a intenção comunicativa e, por conseqüência, a interação. Portanto, como a área de IHC se preocupa com a facilidade do usuário para a realização das tarefas usando os sistemas Web, é imprescindível a preocupação com a aplicação das cores no desenvolvimento desses projetos voltados a esta finalidade (Joly, 1996). Este trabalho visa formalizar Patterns Motivacionais baseado em cores, pensando no projetista Web e também nos usuários de Sites Web. E, sendo as cores um dos elementos de grande importância dentro de uma composição visual, suas potencialidades devem ser reconhecidas e utilizadas com a finalidade de possibilitar uma comunicação eficiente entre o sistema e o usuário. 2.3.1. Cores e seus significados Para Pastoreau (1997), é possível identificar características atribuídas à cultura que o indivíduo está inserido, através do estudo da simbologia das cores, o que ajuda o projetista a tirar proveito desse conhecimento, além de perceber o significado coletivo das cores para aquela sociedade. Para identificar características da cultura que os usuários estão inseridos, para este trabalho, conta-se com o apoio do conhecimento do Senso Comum, que será tratado com maiores detalhes na Seção 2.4. Sabe-se que as pessoas associam cores às diversas situações de suas vidas. Um exemplo disso é a Tabela 2, que mostra que uma mesma cor, pode ter diferentes significados para pessoas de idades, região e culturas diferentes como a cor azul, que pode lembrar: guloseima, piscina, oceano, pijama, hospital, dependendo do contexto em que a pessoa está inserida. É possível associar diferentes significados para as mesmas cores em situações diferentes (Guimarães, 2000). Entre essas situações, estão os movimentos políticos, desfiles 33 de escolas de samba, fatos históricos, sentimentos pessoais, entre outros. Por exemplo, a cor vermelha pode significar para movimentos políticos uma posição mais à esquerda ou algum partido como o PT, enquanto se tratando de sentimentos pessoais, a cor vermelha pode significar amor, coração, paixão. A Tabela 2 exemplifica os dados coletados das pessoas através do projeto OMCS-Br, que será melhor detalhado na Seção 2.4. Tabela 2: Tabela de Cores – OMCS-Br Cor Significado Perfil (sexo, faixa etária, escolaridade, cidade, estado) Guloseima M, 18_29, superior_incompleto, São Paulo, SP Piscina M, 18_29, superior_completo, São Paulo, SP Oceano F, 18_29, superior_incompleto, Três de Maio, RS Pijama M, 18_29, mestrado, Campinas, SP Hospital M, 30_45, latu_senso, Curitiba, PR Menina mimada F, 18_29, mestrado, São Carlos, SP Barbie M, 18_29, superior_incompleto, Fortaleza, CE Patricinha M, 18_29, superior_completo, Ribeirão Pires, SP Menina brincando de bonecas M, 30_45, superior_completo, São Paulo, SP Colar F, 46_65, superior_incompleto, Águas de Lindóia, SP Dente sujo M, 13_17, 2_incompleto, São Vicente, SP Lanchonete M, 13_17, 2_completo, Dracena, SP Dia de sol M, 30_45, latu_senso, Curitiba, PR Mancha M, 30_45, superior_completo, Campinas, SP Banana M, 30_45, superior_completo, São Caetano do Sul, SP Menstruação M, 18_29, superior_incompleto, São Paulo, SP McDonald’s M, 18_29, superior_incompleto, São Paulo, SP Ferrari M, 18_29, superior_incompleto, Florianópolis, SC Tomate M, 30_45, superior_completo, Rio de Janeiro, RJ Cereja F, 46_65, superior_incompleto, Águas de Lindóia, SP Planta M, 18_29, latu_senso, Floripa, SC Maçã verde M, 18_29, superior_completo, Ribeirão Pires, SP Vaga-lume M, 18_29, 2_completo, Florianópolis, SC Alface F, 46_65, superior_incompleto, Águas de Lindóia, SP Abacate M, 46_65, latu_senso, Americana, SP 34 Também é possível associar as cores a diversas condições como: perigo, atenção, qualidade de alimentos, acidez, alcalinidade em experimentos químicos, etc. Por exemplo, os semáforos que possuem três cores: o vermelho indica perigo, o amarelo atenção enquanto o verde indica segurança para prosseguir. Para Buchdid (2005), essas associações dependem de diversos aspectos como os fatores geográficos, culturais e a idade das pessoas. Quando se trata de fatores geográficos, essas associações podem ser facilmente identificadas pela preferência dos indivíduos por certas cores. Por exemplo, na cor verde da Tabela 2, uma pessoa que mora em Florianópolis-SC lembrou- se de planta, já outras pessoas do estado de São Paulo, lembraram de comida, como: maçã verde, alface, abacate. Geralmente, as pessoas de lugares tropicais gostam mais de cores saturadas e com brilho; já os moradores de regiões mais temperadas possuem uma tendência para cores sombrias. Para Silveira et al.(2005), isso se deve ao fato de serem essas cores que elas estão mais acostumadas a ver no seu habitat natural. Para Guimarães (2000), um exemplo de associação dependente de aspectos culturais é a cor branca: No ocidente ela é associada com pureza, virgindade e alegria, sendo muito usada por noivas no dia de seu casamento. No oriente, é a cor da morte e dor, sendo o vermelho a cor convencional para o vestido de noiva. No caso do preto e do branco, a noção da cor é a mesma, o branco como cor positiva e o negro como cor negativa, o que muda é percepção da morte naquela cultura que é entendida como elevação espiritual, e do nascimento. Enquanto isso, Jackson et al. (1994) afirmam que a idade pode contribuir com os significados das cores. Um exemplo disso é que as crianças são atraídas por cores vivas, que são as principais cores de seus brinquedos, pois são cores básicas que não se decompõem em outras cores e a partir das quais se obtém todas as cores do espectro, ou seja, essas cores não precisam ser processadas pelo cérebro tornando-as mais fáceis de visualizar; enquanto cores que são formadas pela composição de duas ou mais cores, precisam de um processamento maior, que somente com o passar da idade isso se torna possível. Já os adolescentes muitas vezes rejeitam o uso de cores e optam por preto, provavelmente com o objetivo de chocar. Enquanto as pessoas mais velhas passam a preferir cores mais neutras. Portanto, para uma boa aplicabilidade das cores, é necessário um estudo sobre o ambiente em que se trabalha, a questão cultural, a idade das pessoas que trabalharão com o site, enfim, todas as características possíveis podem ser úteis na criação de um projeto. Para 35 que se possa formalizar Patterns Motivacionais pensando especificamente em uma certa cultura, conta-se com o apoio do Senso Comum, à partir de dados coletados do perfil dos usuários, como: sexo, idade, escolaridade, cidade e estado. Além do apoio do conhecimento de Senso Comum, este trabalho utilizará a metodologia formalizada no trabalho de Buchdid (2006), para a aplicação correta das cores nos Patterns Motivacionais a serem desenvolvidos. 2.3.2. Contexto Web A Web tem mostrado cada vez mais a capacidade de aumentar a velocidade de comunicação entre as pessoas através de um custo menor, além de aumentar o apoio ao processo criativo e à arte. Um exemplo disso é o e-mail, que tem se tornado cada vez mais um meio comum entre as pessoas. Com isso, a estruturação do conteúdo em páginas Web tem se tornado um ponto fundamental, pois facilita a disposição e organização de um grande volume de dados, além de apoiar uma diversidade de mídias que são usadas para representar essa informação. Para Fraternali e Paolini (Fraternali; Paolini, 2000 apud Gonçalves, 2004), o projeto de páginas Web inclui tipicamente três dimensões, que podem ser considerados no projeto de qualquer site: • Estruturas: envolve a organização das classes e instâncias dos objetos, incluindo localização, armazenamento e conteúdo das páginas; • Navegação: envolve a representação do relacionamento lógico entre os objetos e de acordo com o contexto, habilita ou desabilita caminhos entre as páginas e muda a transparência da informação; • Projeto Visual: determina quais objetos devem estar presentes em uma página e como representá-los. Enquanto Fraternali e Paolini (Fraternali; Paolini, 2000 apud Gonçalves, 2004) dimensionaram os projetos Web apenas com características internas, Bevan (1999) comenta que para usabilidade e acessibilidade serem alcançadas é necessário que a “capacidade do software” como um todo atenda às exigências dos requisitos de qualidade. Essas exigências dependem das características de cada parte do sistema global inclusive hardware, software e usuários. Assim, Bevan (1999) divide a qualidade geral do produto em três tipos, que são: • Qualidade interna - medida pelas propriedades estáticas do código tipicamente através de inspeção (como taxas de erros). 36 • Qualidade externa - medida pelas propriedades dinâmicas do código quando executado (como tempo de resposta). • Qualidade de uso - mede até que ponto o software satisfaz as necessidades do usuário no ambiente de funcionamento (como usabilidade e acessibilidade). Para Bevan (1999), atributos internos apropriados são pré-requisitos para alcançar o comportamento externo exigido, e o comportamento externo apropriado é um prérequisito para alcançar qualidade de uso. Em outras palavras, a qualidade interna influência a qualidade externa, que por sua vez influencia a qualidade de uso. Da mesma forma, a qualidade de uso depende da qualidade externa, que depende da qualidade interna. Assim, quanto melhor forem implementados esses blocos individualmente e quanto melhor for a interligação entre eles, maior será a satisfação de uso do usuário final. Tendo-se então as características definidas por Bevan (1999), a qualidade da página Web como um todo precisa ser definida. E para tal definição, é necessária uma divisão das visões dos envolvidos no projeto, que são definidas por Olsina et al.(1999) baseadas no Padrão ISO (International Standards Organization) que são: visão do usuário, visão do desenvolvedor, visão gerencial ou da organização. • A visão do usuário está relacionada com a visita ao site e a sua utilização, sem levar em consideração aspectos internos de implementação. Os usuários estão interessados em características como desempenho, rapidez de funções de procura e navegação, conteúdo, funcionalidade, confiabilidade, feedback, ou seja, características estéticas, qualidade de uso e acessibilidade. • A visão do desenvolvedor está relacionada aos aspectos internos do site como a sua implementação, taxa de erros, facilidade de manutenção, segurança e conformidade com relação aos requisitos e interesses do usuário. • A visão gerencial ou da organização avalia aspectos de conformidade em relação aos requisitos dos usuários, clientes e desenvolvedores, e também se preocupa com os aspectos de custo e cronograma que envolve o cumprimento de prazos, boa previsão de custo e boa produtividade. Mapeando-se a visão de Bevan (1999) e Olsina et al.(1999), conclui-se que os projetos Web estão relacionados diretamente à visão do usuário. No escopo dessa visão, Bevan (1995) acredita que quanto mais fácil de aprender, memorizar, realizar tarefas, quanto 37 menor a taxa de erros e melhor a satisfação subjetiva do usuário, maior grau de usabilidade tem a interface. Já a visão do desenvolvedor, não é observada diretamente e nem é preocupação dos usuários, mas eles são de grande importância para a qualidade do projeto em geral. Essas características observadas pelo desenvolvedor foram identificadas e definidas por Pressman (2006), como: • Funcionalidade: é o conjunto de características e a capacidade do programa para executar funções que foram declaradas e se tornam necessárias quando o software é usado sob condições específicas. • Confiança: é a capacidade do software para manter seu nível de desempenho quando usado sob condições específicas. É o grau de maturidade, tolerância a erros e a capacidade de recuperação quando o sistema entra em alguma situação de falha. • Eficiência: é a capacidade do software para prover os desempenhos exigidos, relativos à quantia de recursos usados sob condições declaradas, ou seja, é o grau em que o software faz uso otimizado dos recursos do sistema, indicado pelo comportamento com relação ao tempo e aos recursos. • Eficácia: é a taxa de sucesso por falhas, porcentagem de tarefas completadas, número de características ou comandos utilizados. • Manutenibilidade: é a facilidade com a qual o software pode ser reparado. Reparo são as modificações que podem incluir correções, melhorias ou adaptação do software a mudanças de ambiente, nos requisitos e nas especificações funcionais. • Portabilidade: é a capacidade do software de ser transferido de um ambiente para outro, ou seja, a capacidade de adaptar o site em vários ambientes de uma forma estável e atingindo um nível de erros muito baixo. • Segurança: é a capacidade do software de não permitir que informações restritas sejam interceptadas por pessoas desautorizadas. Em aplicações Web a segurança é fundamental, principalmente porque em sites de compras, de transações bancárias, ou nos quais ocorre a transferência de informações sigilosas, os dados devem ser transmitidos de forma protegida. 38 Considerando-se então a visão gerencial uma característica encontrada não só em aplicações baseadas em Web, mas em todos os tipos de projetos, é o imediatismo. Para Pressman (2006), esse atributo é conhecido pelo tempo reduzido (alguns dias ou semanas) para se colocar no mercado um site ou um sistema completo. Dessa maneira, para elaborar sites e projetos Web mais atrativos é necessário se preocupar com várias regras e critérios, bem como com o uso integrado de conhecimentos multidisciplinares, para que o projeto tenha a aprovação por parte do público (Gonçalves, 2004). Para qualquer projeto Web, torna-se muito difícil alcançar todos os parâmetros de qualidade que atendem de forma geral todos os usuários do site, visto que o universo Web é muito amplo e dinâmico, além de existir uma diversidade enorme de requisitos associados a cada projeto e que precisam ser englobados para que o projeto tenha aceitação (Pressman, 2006). Para ajudar na elaboração de tais projetos relacionados ao universo Web, este trabalho visa elaborar Patterns Motivacionais baseados em cores, para que dêem suporte na elaboração dos projetos de forma eficiente e com maior garantia de sucesso. 2.3.3. A questão das cores no Projeto Web Segundo Pedrosa et al.(2005), para adicionar cores em um projeto Web, é necessário um estudo aprofundado sobre o assunto, visto que as cores não são os únicos elementos responsáveis pela comunicação visual, mas se for um recurso bem aproveitado pode resultar em uma rápida e correta assimilação da informação, além de: • Representar associações simbólicas; • Chamar e direcionar a atenção do usuário para pontos importantes; • Enfatizar alguns aspectos da interface; • Diminuir a possibilidade de se cometer erros; • Tornar a interface mais fácil de ser memorizada; • Facilitar a leitura de textos muito longos, entre outras. Para Jackson et al.(1994), Silveira ( 2002) e Pressman (2006), o uso incorreto e discriminado das cores pode trazer resultados indesejáveis e insatisfatórios, que dificilmente 39 são notados pelo projetista. Para que não haja atraso no tempo de resposta do usuário ou uma não assimilação das informações desejadas por parte do usuário, algumas cautelas devem ser levadas em consideração, como: • Analisar o público alvo do site; • Escolher adequadamente as cores para que essas não interfiram na legibilidade da interface; • Saber que as cores podem apresentar características distintas em condições diferentes; • Selecionar as cores de modo que essas não cansem os olhos do usuário e nem o deixe confuso; • Tomar cuidado com questões culturais, geográficas e idade, pois as mesmas cores podem ter significados diferentes em diferentes comunidades; • Verificar se alguns elementos da tela estão agrupados com as mesmas cores e conseqüentemente não possam ser percebidos; • Tomar cuidado para não agrupar com as mesmas cores elementos que não possuam nenhuma relação entre si, a fim de não induzir o usuário a conclusões erradas; • Ter em mente que quando uma cor é colocada em um site todas as cores vão influenciá-la e ela vai influenciar todas as cores, ou seja, as diversas cores em uma interface interagem umas com as outras. Exemplo: a cor da fonte da letra pode acabar com toda a harmonia do site. • Permitir que os usuários customizem as cores propostas, isto é, permitir que eles possam atribuir cores de seu próprio gosto. Seguir esses cuidados reduz em muito a possibilidade do projetista atribuir uma composição de cores (também conhecida como composição cromática) que destrua a comunicação visual do sistema de forma que prejudique a interação com o sistema (Buchdid, 2005). Geralmente, as pessoas apenas se preocupam com a harmonia cromática depois que se deparam com problemas estéticos em um de seus projetos. Para Silveira (2002), harmonizar as cores é diferente de apenas combiná-las. Para tanto, Guimarães (2000) comenta que a composição cromática agradável depende de dois sistemas de regras: o equilíbrio e a harmonia. Entende-se: 40 • O equilíbrio se refere à necessidade natural da nossa percepção visual. Em uma composição equilibrada, todas as tensões dirigidas, todas as forças de atração e repulsão compensam-se mutuamente. Já uma composição cromática desequilibrada, as cores mais fortes (indutoras) induzem as cores mais fracas, podendo resultar em colorações ambíguas e prejudicando a obra como um todo. • A harmonia se refere ao fato de se combinar as cores seguindo determinadas regras que as inter-relacionam, de uma forma agradável. Isso mostra que toda composição harmoniosa está em equilíbrio, mas nem toda composição equilibrada segue regras de harmonização. Para Silveira (2002), utilizar apenas a intuição para projetos de cores pode funcionar, mas na maioria das vezes isso não acontece. Por esse motivo, deve-se utilizar a intuição somada a muita informação e certos tipos de raciocínio para se conseguir a harmonia, de modo que não se corra o risco de elaborar uma composição cromática desagradável e conduzir o projeto a uma não-comunicação. Adotou-se então neste trabalho para a formalização de Patterns Motivacionais, a metodologia de Aplicação de Cores (Buchdid, 2006), que foi formalizada pensando em todas as cautelas a serem tomadas durante o adicionamento das cores em projetos Web. 2.3.4. A metodologia de Aplicação de Cores Para entender melhor a metodologia de Aplicação de Cores de Silveira et al. (2005), é necessário compreender alguns conceitos básicos da Teoria da Cor. Esses conceitos definidos por Silveira (2002) e Guimarães (Guimarães, 2000), serão utilizados neste trabalho. O Círculo Cromático são cores organizadas de forma lógica e distribuídas em um círculo de acordo com cada tom. Serve para facilitar o aprendizado, a utilização e a mistura das cores e serão utilizadas no decorrer desta Seção, conforme a Figura 4 apresentada a seguir: Figura 4: Círculo Cromático das Cores-Pigmento Transparentes (Silveira et al., 2005) 41 A metodologia de aplicação das cores em projetos Web de Silveira (2005) aqui adotada, tem o objetivo de organizar a intuição em uma lógica básica de utilização de três das dimensões da percepção cromática, como mostra a Figura 5: • Estímulo: estimulam os cinco sentidos (visão, audição, tato, olfato e paladar), como: luz, texturas, contrastes, ruídos, chuva, sol, perfumes e gazes. • Sensação: é necessário que o estímulo chegue até nossos órgãos sensoriais, como: cores, sons, sensações táteis, odores e gostos. • Percepção: acontece quando a as sensações chegam ao cérebro e começam a ser interpretadas, como: objetos, espaço, significados e cultura. Figura 5: Teoria da Percepção Para aplicar cores em projetos Web, deve-se considerar as três fases da percepção ao mesmo tempo, conforme apresentada na Figura 5. A Metodologia para aplicação de cores em projetos Web foi proposta considerando as três fases da percepção, conforme Tabela 3. Tabela 3: Metodologia para aplicação de cores baseada na Teoria da Percepção Estímulo Sensação Esquemas de Cores combinações de cores contraste Percepção de Breafing Relações entre a cor e a forma Significado das cores no Ocidente Essa metodologia para aplicação de cores baseada na Teoria da Percepção e nas dimensões da percepção cromática é estabelecida em cinco eixos fundamentais, que são: Esses cinco eixos fundamentais ajudam a organizar as idéias de algumas questões principais, que devem ser levadas em conta em qualquer projeto cromático de 42 ambientes: Qual é(são) a(s) primeira(s) cor(es) que aparecerá(ão) no projeto? Quanto uso desta(s) determinada(s) cor(es)? Como distribuo essa(s) mesma(s) cor(es)? A estrutura da metodologia pode ser vista na Figura 6 a seguir: Figura 6: Estrutura da Metodologia de Aplicação de Cores no Projeto Web (Buchdid, 2006) Nota-se que o briefing corta verticalmente os outros quatro eixos fundamentais, influenciando em decisões de projeto relacionadas aos eixos teóricos. Além do briefing, para saber “Quais cores colocar?”, deve-se levar em consideração a simbologia e o esquema de combinação de cores. Já as perguntas “Quanto uso de cada cor?” e “Como distribuo as cores?” serão respondidas pelo eixo das cores de contraste e pelo eixo relacionado à cor e à forma, respectivamente. Assume-se que nenhuma dessas questões são respondidas com apenas um dos eixos citados, mas com a complementação de cada um deles. 2.3.4.1. Briefing Influencia a aplicação dos 4 eixos teóricos. É um documento criado a partir da entrevista com o usuário, auxiliando o projetista a conduzir o projeto de acordo com as necessidades do cliente, contém informações do projeto como características do público-alvo do site, categoria do projeto, finalidade do projeto, questões culturais que devem ser levadas em consideração, preferências do cliente quanto a estilos e cores, etc. É um documento equivalente ao Documento de Requisitos de Sistemas, utilizado pela ES. 2.3.4.2. Os Esquemas de Combinações de Cores Os “Esquemas de Combinações de Cores”, uns dos eixos teóricos para aplicação das cores em projetos gráficos, são baseados nos aspectos físicos da cor, bem como nos estímulos que resultarão na sensação e na percepção cromática. 43 A cor é definida como uma sensação produzida por certas organizações nervosas, sob a ação da luz. A sensação cromática das ondas luminosas pode se dar de duas maneiras: vinda diretamente da fonte luminosa para os olhos (cores-luz); ou por meio de uma transmissão da fonte de luz para o objeto e do objeto para nossos olhos (cores-pigmento). Segundo Whelan (Whelan, 1994 apud Buchdid, 2006), existem infinitas maneiras de combinar as cores-pigmento e as cores-luz. Uma possibilidade é manipular logicamente os círculos cromáticos, de acordo com os “Esquemas de Combinações de Cores”, que auxiliam os projetistas a criar composições cromáticas harmônicas. Os esquemas apresentados na Metodologia de Aplicação de Cores são: • Esquemas Básicos: São criados essencialmente a partir de um tom do círculo cromático, misturado ao branco, preto, cinzas, castanhos ou dourados (cores que não estão presentes no círculo cromático). I II Figura 7: Esquema básico acromático (I) e esquema básico neutro (II) • Esquemas Dissonantes: Estão ligados à paleta formada a partir dos tons localizados de forma contrária no círculo cromático. Dessa forma, procura-se um equilíbrio entre cores complementares ou contrastantes (distantes dentro do círculo cromático). OU Ci Ci OU B Ci B Mg Mg OU Ci OU Am Mg Am … Am R Figura 8: Exemplo de Esquema dissonante Mg Am R … 44 • Esquemas Consonantes: São formados a partir de tons vizinhos (cores análogas) no círculo cromático. Pode-se utilizar de dois a sete tons para se conseguir a harmonia. OU Ci Mg Am Ci Mg OU Am OU Ci Mg Am … Figura 9: Exemplo de Esquema Consonante • Esquemas Assonantes: São paletas formadas a partir de “triangulações” dentro do círculo cromático. Para Silveira et al. (2004), essas “triangulações” podem ocorrer entre as cores primárias (cores primárias que não podem decompor-se em outras cores e a partir das quais se obtém todas as cores do espectro, como vermelho, amarelo, azul), secundárias (compostas pela mistura de duas cores primárias, como o vermelho é formado pela mistura do magenta e amarelo) ou terciárias (compostas pela mistura de uma cor primária e uma secundária, vizinhas no círculo cromático, como verde-amarelado que é a combinação do verde mais o a cor amarela). Secundárias Cores-pigmento transparentes Primárias Terciárias Figura 10: Cores Pigmento Transparentes 2.3.4.3. As Cores de Contraste É o segundo eixo teórico que fundamenta a metodologia de aplicação de cores em projetos gráficos e se baseia nos aspectos fisiológicos da cor. O sistema visual humano compreende fisiologicamente os órgãos visuais e sua ligação com o cérebro, compostos pelo 45 globo ocular e pelo tecido nervoso ou neural, que leva as informações captadas na retina até o lobo occipital córtex cerebral, no qual as cores são interpretadas. As cores de contraste são classificadas na teoria da cor como cores fisiológicas ilusórias. Para Silveira (2002), as cores ilusórias descrevem três espécies de contrastes: simultâneo, sucessivo e misto. Denomina-se contraste simultâneo das cores o fenômeno registrado ao observarmos os objetos coloridos simultaneamente. Os fenômenos denominados contrastes sucessivos das cores são percebidos a partir da saturação dos olhos pela cor de um objeto durante algum tempo e, deslocando-se em seguida para um anteparo. Aparece então a imagem deste objeto na sua cor complementar. A junção dos dois tipos anteriores é chamada contraste misto, isto é, ele acontece quando se satura a retina com uma cor e carrega-se a cor complementar nesta forma para um suporte que já possui cor, ocorrendo uma mistura da cor fisiológica resultante da saturação com a cor físico-química do anteparo. Uma vez conhecida a lei de contraste de valor e de tom, deve-se manipular as cores sabendo que as complementares tingem os fundos brancos ou coloridos, interferindo assim na harmonia cromática do todo (Buchdid et al., 2005). 2.3.4.4. As Relações entre a Cor e a Forma As relações entre a cor e a forma é um eixo que fundamenta a metodologia de aplicação da cor em projetos gráficos, a relação entre a cor e a forma, também envolve a percepção das cores. Silveira (2002) relata que durante muito tempo, o estudo das cores caminhou paralelamente ao estudo da forma, sem interação alguma. Na maioria das vezes, a relação entre essas duas teorias se deu de maneira intuitiva e empírica. Mas não satisfeitos, alguns autores como Kandinsky e Gerstner tentaram estruturá-la metodologicamente. Os estudos realizados sobre a cor e a forma iniciaram-se com a teoria de Wassily Kandinsky (1866-1944), que ao pintar os triângulos, círculos, e quadrados aleatoriamente de amarelo, azul e verde, percebeu que as cores se realçavam em valor dentro de certas formas, assim como se apagavam dentro de outras (Pintores Famosos, 2000). Para Kandinsky, toda forma primária deveria ter uma correlação com uma cor primária específica de forma que essas se iluminassem mutuamente. Assim ele associou as cores primárias (amarelo, vermelho e azul) e as formas primárias (triângulo, quadrado e círculo), respectivamente. Observa-se, através da Figura 11 apresentada, que no pensamento de Kandinsky o fundamental não é pintar os triângulos necessariamente de amarelo, mas sim notar que as 46 cores e as formas têm um caráter próprio, independente do que representam em significado. Kandinsky realizou vários estudos, pintou vários quadros para chegar à essa correlação entre as cores e as formas (Pintores Famosos, 2000). Figura 11: Correlação entre as Cores e as Formas de acordo com Kandinsky (Buchdid, 2006) Após Kandinsky, Karl Gerstner (1988), aprofundou-se no problema, questionando-se: o que seria uma cor ou uma forma primária? Segundo as teorias de Kandinsky e Gerstner (1988), pode-se perceber que formas “estridentes” são reforçadas perceptivamente pelo AMARELO, as formas “recortadas” são reforçadas perceptivamente pelo VERMELHO e as formas “orgânicas” são reforçadas perceptivamente pelo AZUL. Uma vez descoberta a correlação entre as cores primárias e as formas primárias, Gerstner (1988), associou as formas intermediárias com as cores secundárias num círculo cromático, como mostra a Figura 12 Por exemplo, o violeta, como forma intermediária de dois polígonos regulares, era outro polígono regular, o octógono. O laranja era uma forma mista, formada a partir de dois quadrados. O verde era uma forma sem definição geométrica, mas que se derivava logicamente do amarelo e do azul. Figura 12: Sinais da Cor (Gerstner, 1988) Após compreender os conceitos de Kandinsky e Gerstner (1988), alguns pontos podem ser realçados se tratando de uma arte ou de um site, associando a informação com uma forma e uma cor que juntos se reforçam perceptivamente. Da mesma maneira que pode-se 47 chamar atenção dos usuários com as formas, pode-se esconder informações relevantes, colocando-as em formas que não se intensifiquem com determinadas cores. 2.3.4.5. A Simbologia das Cores na Cultura Ocidental O último eixo proposto pela metodologia de aplicação de cores em projetos gráficos está associado aos aspectos culturais e à percepção sobre as cores que cada indivíduo inserido em uma determinada cultura tem. É importante ressaltar que em qualquer cultura, as cores podem trazer consigo bons e maus significados. Os autores Guimarães (2000), Jackson et al.(1994), Rousseau (1980), Silveira (2002) e Pastoreau (1997) citam alguns desses significados para as cores na cultura ocidental: • Vermelho: cor do sinal, da marca, do perigo e da proibição, da sexualidade, da paixão, amor e erotismo, cor do pecado, do dinamismo e da criatividade, da alegria e da infância, do luxo e da festa, do sangue, do fogo, da guerra e da raiva, da matéria e da energia. • Amarelo: cor da luz e do calor, do sol e do verão, da prosperidade e da riqueza, da alegria, da energia, cor da mentira, da covardia e da traição, cor do declínio, da melancolia e do outono, cor da doença e loucura. • Azul: cor preferida por mais da metade da população ocidental, cor do infinito, longínquo e do sonho, da fidelidade e do amor, da fé, cor da paz, do frio e da água, do céu e do mar, cor da espiritualidade. • Verde: cor do destino, da palavra dita e da desdita, da fortuna e do dinheiro, do acaso e da esperança, cor da natureza e ecologia, da higiene e da saúde, cor da juventude, cor dos marcianos, cor da esperança e da segurança, cor da inexperiência, da inveja e da ganância. • Branco: cor da pureza, castidade, virgindade e inocência, cor da higiene, leveza e da limpeza, do frio que é estéril, cor da neve, cor da paz, cor da sabedoria e velhice, cor da palidez, da aristocracia, da monarquia, ausência de cor, cor do divino. • Preto: cor da morte e da falta, do pecado e da desonestidade, da elegância e da modernidade, cor da autoridade, cor da renúncia e da religião, cor do inferno e diabos, cor do ódio e da tristeza, cor do medo, das trevas e da noite, cor do carvão e do poder. Destaca-se que nenhum dos cinco eixos fundamentais da metodologia podem responder isoladamente as perguntas propostas: Qual é(são) a(s) primeira(s) cor(es) que aparecerá(ão) no projeto? Quanto uso desta(s) determinada(s) cor(es)? Como distribuo 48 essa(s) mesma(s) cor(es)? Mas podem auxiliar o projetista na tomada de decisões com relação ao projeto cromático. Para escolher então quais as cores devem ser colocadas em um projeto com o apoio da Metodologia de Aplicação de Cores, é necessário analisar o Briefing e determinar as características do projeto que podem influenciar no projeto cromático, como: propósitos e objetivo do projeto, público alvo, contexto que o projeto está inserido e preferências do cliente. Contudo, escolher a cor que mais se identifica com o contexto do site. Em seguida, deve-se recorrer aos Esquemas de Combinação de Cores (básico, consonante, etc) para escolher as outras cores passíveis de utilização, de acordo com o pedido do cliente. Após as cores serem escolhidas, é necessário saber a quantidade que vai ser utilizada de cada cor, através do apoio do eixo das Cores de Contraste, a fim de destacar ou esconder pontos relevantes da interface. Finalmente, o eixo da Relação das Cores e a Forma ajuda na distribuição e na localização das cores, utilizando formas adequadas para realçar ou esconder as informações mais ou menos importantes dentro do projeto. Segundo Guimarães (2000) ao se trabalhar com a aplicação intencional das cores, trabalhar-se-á com a informação “latente”, que será percebida e decifrada pelo sentido da visão, interpretada pela nossa cognição e transformada numa informação atualizada. Enfim, os usos das cores podem contribuir para facilitar o acesso e a compreensão das informações contidas na interface, agindo direta e indiretamente na disseminação do conhecimento, na medida em que os sistemas de interface têm potencial de comunicação de longo alcance. Pois, através desses sistemas, textos, artigos, idéias, propagandas, são transmitidos a vários usuários, em tempo real, independente da localização geográfica. Posto assim faz-se necessário o conhecimento de Senso Comum, que será tratado na próxima Seção, a fim de buscar a compreensão das diversas variáveis envolvidas na decisão de uso das cores nas interfaces digitais e da interação das mesmas. Tais como os aspectos físicos, psicológicos e culturais da cor, de modo que sejam estabelecidos critérios para análise do uso deste recurso em sites com a finalidade de motivar os usuários na aquisição de informações e interação nesses ambientes. 49 2.4. Senso Comum Há décadas tem-se como desejo o desafio de construir máquinas capazes de simular o comportamento humano, que auxiliem as pessoas em suas tarefas através de uma interação mais amigável, como cita Carvalho (2006). Uma das maneiras do computador adquirir essa capacidade é através do conhecimento sobre fatos de Senso Comum que os seres humanos possuem. Para Rubem Alves (1995), senso comum é resultante da herança de um grupo social e das experiências atuais de cada pessoa. Não há análise no senso comum, pois é o que as pessoas usam no seu quotidiano, o que é natural e o que elas pensam que é verdade. É baseado em fontes de conhecimento entre as quais o bom-senso, a tradição, a intuição e a autoridade de um conhecimento específico. A fim de construir bases de conhecimento de Senso Comum e superar o desafio de conceder às máquinas certa capacidade de utilizar o conhecimento da vida cotidiana do ser humano, iniciou-se o projeto CommonSense (OMCS) desenvolvido pelo Media Laboratory do Massachusetts Institute of Technology (MIT) (Singh, 2002). O projeto norte americano inspirou o desenvolvimento do projeto brasileiro Open Mind Common Sense no Brasil (OMCS-Br), desenvolvido pelo Laboratório de Interação Avançada (LIA) da Universidade Federal de São Carlos (UFSCar) (Carvalho, 2007). Esta seção tem como objetivo apresentar os conceitos concernentes ao termo senso comum, bem como o projeto OMCS-Br, o qual será utilizado neste trabalho. 2.4.1. Definição Para Mueller (1998), a definição de senso comum é muito polêmica, devido à abrangência das definições encontradas na literatura. Pela definição de Marvin Minsky, citada por Singh (2002), senso comum são “as habilidades mentais que a maioria das pessoas compartilha”. Para Liu e Singh (2004), deve-se ter em mente que “o conhecimento de senso comum é amplamente refutável e sensível ao contexto”. Eles não estão relacionados à verdade absoluta das coisas e sim à verdade aceitável dentro de um contexto temporal e cultural. Por exemplo, quando alguém reclama de dores no fígado, esta pessoa pode fazer um chá de boldo que era usado pelas bisavós, sem, no entanto conhecer o princípio ativo das folhas e seu efeito nas doenças hepáticas; para aquele grupo específico, no tempo em que o fato foi coletado, o fato é de senso comum. 50 No contexto deste trabalho, a definição de senso comum utilizada é a mesma do projeto OMCS-Br: um conjunto de fatos conhecidos pela maioria das pessoas, “abrangendo uma ampla parte das experiências humanas, conhecimento sobre aspectos espaciais, físicos, sociais, temporais e psicológicos do dia-a-dia dos seres humanos” (Liu et al., 2004). 2.4.2. O Projeto OMCS-BR O projeto OMCS-Br é um projeto gerado a partir de uma colaboração entre o LIA e o MediaLab-MIT para o seu desenvolvimento. O projeto explora a Web como forma de construção da base de senso comum, através de uma arquitetura para armazenamento e manipulação dos fatos colhidos para prover mecanismos de inferência e raciocínio automático. Portanto, contam com contribuições de pequenas declarações de voluntários brasileiros, tornando a construção da base de conhecimento um trabalho colaborativo. Para o OMCS-Br as contribuições dos voluntários podem ser realizadas através do Site, pelo endereço: http://www.sensocomum.ufscar.br. As próximas seções têm o objetivo de descrever em detalhes todo o projeto OMCS-BR, a arquitetura geral do projeto, os projetos desenvolvidos utilizando a base de senso comum brasileira e também a utilização de Senso Comum expressando cultura através das Cores. 2.4.2.1. A Arquitetura do Projeto A Figura 13 apresenta esquematicamente a arquitetura que o projeto OMCS-Br utiliza para colher e utilizar fatos de senso comum, e será exemplificada a seguir. Os fatos fornecidos no site são armazenados na base de dados OMCS-Br e usados para retro-alimentar as atividades do site que são baseadas em templates, relacionamento expresso na Figura 13 pela seta 1. Num segundo momento (seta 2) os fatos são submetidos ao módulo gerador da rede semântica ConceptNet, que com o auxílio do Curupira (Martins et al., 2002) que é um analisador de sentenças da língua portuguesa desenvolvido pelo NILC (http://www.nilc.icmc.usp.br/nilc/index.html), Grupo de Pesquisa do ICMC-USP e o Normalizador desenvolvido pelo LIA (Tsutsumi, 2006) (seta 3), processa as sentenças, gera os nós da rede, estabelece as relações entre eles, produzindo a ConceptNet (seta 4). A notação bidirecional da seta 4 se deve ao fato da ConceptNet ser construída em três fases: extração, normalização e relaxamento e de, nas duas primeiras fases serem geradas versões prévias da ConceptNet que são submetidas novamente ao módulo gerador da rede para 51 refinamento. Com a ConceptNet pronta, podem ser construídos aplicativos incorporando o raciocínio de senso comum. Esses aplicativos submetem suas entradas, representadas textualmente, à API (Application Programming Interface ou Interface de Programação de Aplicativos) de manipulação da ConceptNet, que por sua vez utiliza o Curupira (Martins et al., 2002) e o Normalizador (Tsutsumi, 2006) para processá-las de tal forma que se possam percorrer os nós da ConceptNet e inferir coisas sobre as entradas fornecidas, baseando-se no senso comum previamente fornecido pelos usuários do site. Os resultados das inferências retornam, então, à aplicação que pode trabalhar sobre eles e, por fim, exibi-los ao usuário. Figura 13: Arquitetura do Projeto OMCS-Br Todo o processo descrito de uma forma geral na Figura 13 será descrito em maiores detalhes nas próximas seções para um melhor entendimento. 1.4.2.1.1. O Site A criação de um Site, disponível em http://www.sensocomum.ufscar.br, foi a maneira mais apropriada encontrada para que pessoas de vários lugares e culturas pudessem contribuir com seu Senso Comum. A Figura 14 apresenta a interface principal do Site. Para que o usuário contribua com a base de dados do senso comum, é necessário Login e Senha, criados através de um simples cadastro no próprio site que possui filtros como: sexo, faixa etária, escolaridade, cidade e estado, que podem ser utilizados para análise dos dados, quando há necessidade de diferenciar o Senso comum de certas regiões e culturas, como serão utilizados para análise do senso comum sobre as Cores, exemplificado na Tabela 2 na Seção 2.3.1. 52 Figura 14: Site do Projeto OMCS-Br O Site atualmente possui 24 atividades distintas para a coleta de dados de senso comum através do preenchimento de templates (modelos), que são sentenças incompletas com espaços a serem completados de tal forma que a sentença criada represente para o contribuinte um fato de senso comum, conforme a Figura 15, que mostra um template da atividade Cores. Esses templates possuem duas partes: uma estática e outra dinâmica. A parte dinâmica da sentença é uma retro-alimentação de fatos já cadastrados na base, isso significa que fatos que já foram cadastrados são utilizados para a inserção de novos dados. No exemplo da Figura 15, pode-se dizer que a parte que está em verde, no caso a palavra “piscina” é a parte retro-alimentada a partir da base. De uma forma mais clara, dizemos que num primeiro momento, como pode ser observado na Figura 15, o primeiro template do tema “Cores” (“A cor me lembra um (a) _________”) é apresentado a um colaborador. O colaborador completa-o com a palavra “piscina” e a sentença “A cor me lembra um (a) piscina” é armazenada na base de conhecimento. Posteriormente a palavra “piscina” é utilizada para compor outro template, como é apresentado no segundo template do tema “Cores” (“piscina me faz lembrar a cor: __________”), para o espaço em branco o usuário preenche o nome de uma cor. 53 Figura 15: Exemplo de templates e processo de retro-alimentação do Projeto OMCS-Br A entrada de dados nos templates é livre pelos colaboradores, portanto, pode ocorrer a entrada de caracteres que não tenham sentido, palavras de baixo calão, entre outros problemas. Por esse motivo, para permitir que as sentenças armazenadas dos templates sejam utilizadas para retro-alimentação, foi criado um sistema de revisão para decidir se as informações de uma sentença serão ou não utilizadas na retro-alimentação e outros templates do site. Conforme Figura 16, essa tarefa é realizada manualmente e é disponibilizada através do site do projeto, porém o acesso é restrito aos desenvolvedores do projeto. É válido mencionar que a revisão não isenta que algumas entradas não desejadas para a retro-alimentação, ou para a ConceptNet, passem despercebidas, visto que é um processo manual, onde se está em contato com um grande número de informações ao mesmo tempo. I II III IV Figura 16: Interface do Sistema de Revisão das colaborações realizadas no site OMCS-Br 54 Como é visto na Figura 16, a interface do sistema de revisão do site OMCS-Br oferece as opções: aceitar, manter e rejeitar uma determinada sentença em revisão. Os critérios adotados para cada opção são: • Aceitar (I): Quando a sentença está correta ortograficamente e gramaticalmente. • Manter (II): Em caso do revisor possui dúvidas em relação a como proceder, e mantém a sentença para uma análise posterior. • Rejeitar (III): Quando na sentença ocorre seqüência de caracteres sem sentido; palavras ortograficamente incorretas; palavras de baixo calão que possam refletir a cultura de uma determinada região. Observa-se também a opção “retro-alimentar” (IV), que indica se uma sentença deve ou não ser utilizada no processo de retro-alimentação, e para a escolha dessa alternativa, utiliza-se os mesmos critérios das três primeiras opções, ou seja, as palavras são aceitas para retro-alimentar outros templates se não há erros de gramática e ortografia. Esse mecanismo de “retro-alimentação” existe devido à ausência de um corretor ortográfico automatizado, evitando-se desse modo que os dados inseridos incorretamente possam atrapalhar a formação de uma nova sentença. Vale ressaltar que não é avaliado o sentido da sentença após ter sido montada pelo colaborador, como exemplo, se o colaborador preencher o template como “Céu me faz lembrar a cor amarela”, significa que para ele que isso é um fato de senso comum, e como já citado por Rubem Alves (1995), não há análise no senso comum, pois é o que as pessoas usam no seu quotidiano, o que é natural e o que elas pensam que é verdade. 1.4.2.1.2. Módulo Gerador da ConceptNet As sentenças obtidas pelos templates do site OMCS-Br são armazenadas em língua natural na base de dados, porém é necessário serem convertidas para um forma que pode ser utilizada por um computador. Para isso, realiza-se um processamento, que ocorre em três fases: Extração, Normalização e Relaxamento, que são o Módulo Gerador da ConceptNet. • Fase da extração: Os fatos de senso comum armazenados são submetidos à fase de extração, que dá origem a um conjunto de fragmentos de sentenças, que irão compor um nó da rede semântica, conforme a Figura 20. É atribuído um tipo de relação a esses fragmentos. Por exemplo: para a sentença ‘Pessoas enviam cartão postal quando viajam’, após a fase de extração será retornado “MotivationOf ‘enviam cartão postal’ ‘viajam’”, 55 como apresentado na Figura 17 . Alguns dos tipos de relações possíveis são (Liu et al., 2004): MotivationOf, UsedFor, CapableOf, EffectOf, entre outras. Ressalta-se que foi desenvolvido no projeto OMCS-Br todas as negações das possíveis relações, como: NotMotivationOf, NotUsedFor, NotCapableOf, NotEffectOf para sentenças negativas fornecidas pelos colaboradores. Figura 17: Exemplo da Fase da extração • Fase da normalização: As declarações extraídas na Fase de extração são normalizadas. Na Fase da normalização, há o curupira (Martins et al., 2002), um parser que é capaz de identificar a estrutura sintática, como: verbo, substantivo, entre outros. Ele encarrega-se de etiquetar as sentenças e enviá-las para o Normalizador (Tsutsumi, 2006), que por sua vez utiliza o dicionário Delaf (Muniz, 2004) cujo objetivo é colocar a sentença etiquetada em sua forma canônica, ou seja, os substantivos e os adjetivos da relação são colocados no singular e no grau afirmativo, bem como os verbos são colocados no infinitivo, conforme exemplificado na Figura 18. Figura 18: Exemplo da Fase da normalização • Fase do relaxamento: A Fase de relaxamento recebe como entrada as relações já normalizadas, e adiciona os metadados f e i, de acordo com a Figura 19. O f é o número de vezes em que uma relação foi encontrada, ou seja, tendo uma relação repetida o valor de f é incrementado e o i é a quantidade de vezes em que uma relação é gerada a partir de relações já existentes. Figura 19: Exemplo da Fase do relaxamento 56 1.4.2.1.3. A ConceptNet A ConceptNet é uma rede semântica gerada a partir do Processamento de sentenças de senso comum coletadas através do site, citado anteriormente. A Figura 20 mostra um exemplo de parte da ConceptNet, onde os nós contém conceitos de senso comum e os arcos são as relações existentes entre os nós. matar saudades viajar UsedFor MotivationOf Enviar cartão postal alegrar pessoas CapableOf EffectOf mandar notícias Figura 20: Exemplo de uma Rede Semântica. Pode-se ver na Figura 20 um exemplo simples da ConceptNet, porém a rede de conceitos permite conexões complexas, conforme Figura 21, capaz de relacionar os conceitos gerados diretamente de uma sentença, e também gerados através de inferência, ou seja, é capaz de processar informações nela contida. Figura 21: Exemplo de parte da ConceptNet do Projeto OMCS-Br 1.4.2.1.3.1. Redes Semânticas Rede semântica é uma notação gráfica composta por nós representam conceitos e pelos arcos que representam relações semânticas entre os conceitos. As redes semânticas podem ser usadas para representação de conhecimento, ou como ferramenta de suporte para sistemas automatizados de inferências sobre o conhecimento (Falbo et al.,2004). 57 1.4.2.1.3.2. Ontologias Uma ontologia é um modelo de dados que representa um conjunto de conceitos dentro de um domínio específico e os relacionamentos entre estes, geralmente descrevem (Almeida et al., 2003): Indivíduos (os objetos básicos); Classes (conjuntos, coleções ou tipos de objetos); Atributos (propriedades, características ou parâmetros que os objetos podem ter e compartilhar) e Relacionamentos (as formas como os objetos podem se relacionar com outros objetos). Baseado na Figura 22 que apresenta os tipos de representação de ontologias (Yaguinuma, 2007; Uschold et al.,2004) classifica-se Redes Semânticas como uma Ontologia (Liu et al., 2002). Pois, a princípio, Redes Semânticas se enquadram em Ontologias Formais e Inferências (parte vermelha), pois permite inferências. Em um segundo momento, verifica-se que Redes Semânticas podem ser classificadas entre Taxonomias formais, Frame (OKBC) e Lógicas de Descrição. Taxonomias formais possuem poucas relações, como: IsA e TypeOf; Frames tem uma estrutura semelhante a de Redes Semânticas pois são representados por conceitos e relações (Araújo, 2003). Porém, Redes Semânticas não são mais que Lógicas de Descrição (OWL DL), pois essa já possui classes, atributos, relacionamentos, ou seja, uma hierarquia estruturada (Haase et al, 2005). Redes Semânticas Figura 22: Tipos de representação de ontologias (Yaguinuma, 2007; Uschold et al.,2004) 58 Por fim, pode-se dizer que ontologias possuem uma hierarquia detalhada e estruturada, como no princípio de orientação a objetos, criada para um domínio de conhecimento específico, enquanto as redes semânticas por estarem conectadas praticamente em um mesmo nível agregam vários significados e interpretações, adequando-se a aplicações de domínios mais amplos e desconhecidos como o conhecimento de senso. Ressalta-se que essa definição excede a relação SuperThematicKLine, que é uma abstração de um conceito, como exemplo: dor de dente é um conceito e dor é a abstração do conceito dor de dente. 1.4.2.1.4. A API A API tem como objetivo facilitar o acesso ao conhecimento da ConceptNet, através de oito funções, conforme a Figura 23. As primeiras funções: Navegar, Contexto, Projeção e Analogia disponibilizam buscas com entradas simples, ou seja, uma única palavra, como por exemplo, “cor”, sendo que devem estar na forma canônica. Exemplo da palavra: “Cor” com a Função Navegar Funções de buscas de sentenças ou pequenos trechos Funções de buscas de palavras simples Retorno da API: Relação, Conceito, Freqüência, Inferência Figura 23: Exemplo da interface da API utilizando a função “Navegar” As outras quatro funções da API que são: Inferir conceito, Inferir tópico, Inferir humor e Sumarizar, disponibilizam uma busca com entradas de sentenças inteiras que podem ser sentenças ou pequenos trechos de textos, onde essa entrada é submetida ao Curupira e Normalizador, que dividem e normalizam em estruturas de acordo com o padrão dos dados da ConceptNet (Liu et al., 2004). Essas funções identificam o tópico principal do texto, classificam o texto em gênero, consideram o contexto para adquirir o sentido de uma palavra, fazem analogias para reconhecer novos conceitos e identificam o humor expresso no texto (Pereira, 2007). 59 1.4.2.2. Aplicações computacionais usando Senso Comum O LIA é um grupo de Pesquisa e Desenvolvimento, cujas atividades são voltadas para a especificação, projeto e implementação de ferramentas aplicáveis à área de Aprendizado Eletrônico (AE). Para tal, é realizada a coleta e a utilização de Senso Comum. As pesquisas relacionadas ao senso comum tem sido realizadas no contexto do projeto OMCS-Br, que adota uma abordagem colaborativa, considerando o fato de que todas as pessoas podem auxiliar na construção de uma base de conhecimento de senso comum, uma vez que esse é um tipo de conhecimento inerente a todo ser humano. Serão apresentados alguns exemplos das ferramentas desenvolvidas no LIA: A Figura 24 apresenta o Passo 2 da representação computacional do PACO (Carvalho, 2007), um framework de planejamento de Ações de Aprendizagem, que consiste em sete passos que guiam professores na elaboração de um plano de execução para a AA que está sendo planejada. O PACO oferece apoio de senso comum aos professores, que podem, pela análise do conhecimento apresentado na ferramenta, decidir quais tarefas de aprendizagem devem ser realizadas na ação, para trabalhar as necessidades do público alvo considerado. Por essa análise pode-se identificar conhecimentos equivocados que devem ser esclarecidos, tópicos de interesse geral que o público alvo deseja conhecer, exemplos para serem utilizados durante a AA e um vocabulário comum e de fácil entendimento para o público alvo. Passos do Planejamento de AA Apoio do conhecimento de Senso Comum Escolher qual o tópico que se irá trabalhar Figura 24: PACO = Framework de Planejamento de Ações de Aprendizagem Apoiadas por Computador (Carvalho, 2007) 60 A Figura 25 apresenta a interface do módulo do jogador do jogo “O que é o que é?” (Ferreira, 2007; Pereira, 2007). Esse é um jogo de adivinhação, baseado em conhecimento de senso comum, proposto para trabalhar os temas transversais definidos pelo Ministério da Educação e Cultura (MEC): ética, meio ambiente, pluralidade cultural, trabalho e consumo, saúde, educação sexual. O jogo conta com dois módulos (o módulo do editor e o do jogador), sendo que no primeiro módulo é possível, com o auxílio de conhecimento de senso comum, compor uma série de dicas relacionadas a uma palavra-secreta que deve ser adivinhada pelo jogador. As dicas de senso comum apresentam um vocabulário próximo ao público alvo e trazem exemplos que fazem parte do seu contexto cultural. Dessa forma, é oferecida ao professor uma ferramenta que pode ser utilizada para sedimentar o conhecimento apresentado em sala de aula, promover a interação entre os alunos que podem preparar e jogar o jogo de acordo com o tema que o professor deseja trabalhar, ou mesmo sedimentar o conhecimento apresentado em sala de aula. Representa uma face do dado que alterna de acordo com os tópicos existentes. Dicas apresentadas a partir da escolha de uma opção do quadro de dicas. Campo para digitar a palavra chave. Dicas apresentadas para ajudar o usuário descobrir a palavra chave, essas dicas são definidas pelo professor com o apoio do senso comum. Tempo de dois minutos ou até quatro tentativas para acertar a palavra chave. Figura 25: Módulo do Jogador do jogo “O que é? O que é?” (Ferreira, 2007; Pereira, 2007) Cognitor é uma representação computacional para a CogLearn, uma Linguagem de Padrões, que reúne Padrões de Pedagógicos, Padrões de IHC e Padrões 61 Híbridos (Talarico et al., 2006). Através do Cognitor, professores podem construir materiais de aprendizagem bem estruturados e organizados, de maneira a facilitar a interação entre estudantes, professores e conteúdo, e o processo de aprendizagem. A ferramenta conta um módulo de senso comum, objetivando apoiar professores a elaborar materiais de aprendizagem contextualizados às necessidades de seus aprendizes, além de contar com o apoio de mapa de conceitos e analogias. A Figura 26 apresenta a interface principal do Cognitor que possui seis áreas distintas: (I) Área de planejamento e organização de material instrucional; (II) Área de planejamento da interação; (III) Barra de ferramentas de inserção de mídia e de publicação de conteúdo; (IV) Área de Edição de Página; (V) Área de Controle de Objetos e (VI) Propriedades da Mídia. Ressalta-se que a área (I) de planejamento e organização de material instrucional do Cognitor, é onde ocorre o uso efetivo da base de senso comum. Barra de ferramentas: Inserção de mídias e publicação de conteúdo (III) Área de edição de página (IV) Área de planejamento e organização de material instrucional (I) (VI) Propriedades da mídia Área de controle de objetos (V) Área de planejamento da interação (II) Figura 26: Cognitor = Framework Computacional para a Linguagem de Padrões CogLearn (Carlos, 2007) 1.4.3. Senso Comum e Cores expressando cultura – OMCS-Br É muito importante o conhecimento sobre cultura para o projeto de interfaces, pois a interface deve conter elementos que sejam agradáveis, úteis e familiares ao usuário. Para Borgman (1992), estilo de aprendizagem, orientação espacial, preferências de cores e uso 62 da linguagem variam de acordo com a cultura. Portanto, é trabalhoso projetar interfaces para uma cultura desconhecida ou abrangendo várias culturas. O processo de considerar preferências culturais no projeto de interfaces, segundo Huatong Sun (2001), é realizado em dois níveis: 1) Ajuste de características do software, incluindo tradução, datas, pesos, endereços, moeda, etc. para refletir as convenções e as necessidades do público alvo; 2) Ajuste da estética, imagens, cores, lógica, padrões de funcionalidade e comunicação conforme o público alvo. Huatong Sun (2001) cita também em seu artigo, alguns exemplos para demonstrar a importância dos aspectos culturais nos projetos de interface: • Nos elementos da interface: Os usuários brasileiros gostam de cores mais vibrantes e páginas com muitas figuras. Os alemães sentem-se satisfeitos com links organizados em ordem alfabética. • Símbolo Cultural: Os brasileiros e os chineses se sentem confortáveis quando vêem figuras de suas culturas (como: Pão de Açúcar; Flor de lótus, uma flor popular na China). • Modos de mostrar símbolos culturais: os alemães preferem componentes textuais, já os brasileiros e os chineses preferem componentes visuais coloridos. Mesmo com a importância dessas questões, muitos desenvolvedores ainda encontram uma grande dificuldade em obter apoio para realizar pesquisas a respeito da cultura dos usuários que irão interagir com a interface projetada (Marcus, 2002). Acredita-se que o projeto OMCS-Br possa contribuir para transpor tais dificuldades, uma vez que o projeto têm colhido informações sobre o que as pessoas acham de determinadas cores, do que se lembram quando vêem uma certa cor, ou mesmo qual a cor as pessoas associam com certos conceitos que são apresentados. Os fatos de Senso Comum estão sendo coletados continuadamente, já que a idéia de “senso comum” de uma determinada cultura muda com o tempo (Tsutsumi, 2006). 2.5. Considerações Finais Esse capítulo apresentou as Referências Bibliográficas realizadas no decorrer deste trabalho. A primeira parte mostrou o conceito de Patterns, os Patterns Organizacionais da ES, os Patterns Motivacionais de IHC e por fim uma Linguagem de Padrões que facilita a 63 escrita de um Pattern. Baseado nesses conceitos e nos exemplos dados, os Patterns a serem desenvolvidos serão inspirados e posteriormente classificados nos Patterns Motivacionais de IHC, adotando-se a Linguagem de Meszaros et al.(1996) já citada a partir da observação da necessidade das pessoas em relação às suas motivações. Baseado na idéia de que há duas maneiras para a formalização de Patterns: observação ou consulta a um especialista da área, será utilizado neste trabalho para a formalização dos Patterns Motivacionais, a Metodologia das Cores, criada pela especialista Luciana Martha Silveira (Silveira et al.,2005), formalizada em Buchdid (2006). Também foi apresentado o estudo sobre Senso Comum e o projeto OMCS-Br, que serão utilizados para o desenvolvimento deste trabalho. Sabe-se que o uso do conhecimento de senso comum pode ajudar os projetistas no desenvolvimento de vários projetos. O objetivo deste trabalho é explorar as possibilidades do uso do conhecimento do senso comum na formalização de Patterns Motivacionais, através da entrada de dados de diferentes culturas e costumes. 64 CAPÍTULO 3 - PROPOSTA DE TRABALHO 3.1. Considerações Iniciais Considerando as questões do trabalho colaborativo apoiado pelo computador, principalmente através de sistemas Web, a utilização das cores no desenvolvimento de sistemas para tal apoio é um grande desafio para profissionais da área, uma vez que o usuário participante da equipe de trabalho deve se sentir motivado e engajado a usar o site e desenvolver suas tarefas. A multidisciplinaridade como característica intrínseca desse tipo de sistemas Web tem uma complexidade difícil de ser gerenciada e, mesmo quando essa tarefa é concluída, é difícil de ser registrada (Buchdid, 2006). Porém, com o intuito de oferecer diretivas e apoio a tarefa de organização e promoção da harmonia do projeto Web e da motivação pelo uso de sites de apoio ao trabalho colaborativo, propõe-se a formalização de Patterns Motivacionais considerando as questões culturais e o contexto dos participantes da equipe de trabalho colaborativo. Essa formalização, buscando no conhecimento de senso comum o apoio para a identificação dos problemas recorrentes e das soluções de sucesso, é o desafio proposto por este trabalho. A seguir, será apresentada em detalhes a proposta de projeto deste trabalho de mestrado. O qual está subdividido em mais quatro seções, que contêm nesta ordem, a justificativa para a escolha do tema e a relevância do trabalho, a descrição do trabalho, o cronograma de execução das atividades a serem desenvolvidas, e os resultados esperados com o desenvolvimento deste projeto. 3.2. Justificativa Detalhada e Relevância do Trabalho Na literatura, são poucos os Patterns Motivacionais existentes para auxiliar desenvolvedores na criação de projetos Web de apoio à equipe que desenvolve esse tipo de trabalho, mas esses têm aumentado devido à preocupação dos desenvolvedores de manter seus projetos utilizados de forma satisfatória pelos usuários (Clear et al., 2005; Löwgren, 2005; Schümmer et al., 2007a; Schümmer et al., 2007b; Lukosch et al,. 2007). Este trabalho tem como enfoque principal a formalização de Patterns Motivacionais baseados em cores, que auxiliem os projetistas no desenvolvimento de projetos Web para apoiar o trabalho colaborativo, de forma que reforcem a intenção comunicativa e a interação dos usuários membros da equipe através do uso das cores. As cores podem ajudar os 65 projetistas a destacar pontos importantes, bem como facilitar a leitura do conteúdo do site e, conseqüentemente, aumentar a satisfação do usuário, seu engajamento na colaboração e persistência na realização de suas tarefas. Outro ponto importante, considerado neste trabalho, é a utilização da base de conhecimento de senso comum, esse uso vem sendo tratado pelo LIA em outros projetos, e este trabalho especificamente tem como objetivo utilizá-la na formalização dos Patterns Motivacionais para usuários de Sistemas Web. Ressalta-se que patterns são alternativas interessantes para expressar conhecimentos bem sucedidos, através de uma maneira estruturada, o que colabora com o desenvolvimento de sistemas. Assim acontece com os Patterns Motivacionais aqui propostos para ambientes Web de apoio ao trabalho colaborativo, que têm como característica principal o elevado grau de interatividade, onde a questão das cores se torna determinante para seu sucesso, considerando a necessidade de engajamento e dedicação de cada elemento participante da equipe. Desse modo, acredita-se que os Patterns Motivacionais baseados em cores possam contribuir significativamente para os projetistas de sites dessa natureza, que não têm necessariamente um conhecimento profundo sobre o uso das cores em ambientes computacionais Web colaborativos. 3.3. Descrição do Trabalho Conforme citado no decorrer deste trabalho, um dos desafios para a área de IHC encontra-se no desenvolvimento de técnicas eficientes para documentar e comunicar o conhecimento que os projetistas adquiriram e aplicaram em determinadas circunstâncias. Vários pesquisadores da área, como Jennifer Tidwell (1999), Jan Borchers (2001), Martijn van Welie (2003) argumentam que os Patterns são as melhores alternativas para se expressar as guidelines e checklists disponíveis no domínio da IHC. Percebe-se que a questão das cores no projeto Web é essencial. Portanto, se a área de IHC se preocupa com a usabilidade nos sistemas Web, é imprescindível a preocupação com a aplicação das cores no desenvolvimento dos projetos voltados a essa finalidade. Sendo a questão das cores no projeto Web uma questão complexa e que merece ser melhor explorada, o presente trabalho propõe investigar o uso de senso comum na 66 formalização de Patterns Motivacionais baseados em Cores, no sentido de contribuir para que o projeto Web seja melhor desenvolvido, tenha boa aceitabilidade e apresente um maior grau de usabilidade e satisfação do usuário de projetos Web. Com os dados coletados da base de Senso Comum, será utilizado a Metodologia de Aplicação de Cores formalizada por Silveira et al.(2005). Essa metodologia ajudará na organização e utilização correta dos dados coletados do Senso Comum, para a formalização dos Patterns a serem criados. 3.4. Cronograma de Execução Para a realização da proposta definida neste trabalho, serão realizadas as seguintes atividades: 1. Realizar novos templates para coleta de Senso Comum sobre Cores. 2. Fazer uma coleta dos dados da base de Senso Comum em relação às Cores coletados no Site. 3. Iniciar uma análise dos dados coletados até o momento utilizando a Metodologia de Aplicação de Cores. 4. Associar as Cores analisadas como Patterns Motivacionais, tanto no reconhecimento dos problemas recorrentes quanto das soluções de sucesso. 5. Formalizar os Patterns Motivacionais. 6. Realizar o estudo de caso. 7. Analisar os resultados obtidos e propor melhorias para os Patterns formalizados. 8. Escrever a dissertação. 9. Defesa para obtenção do título de mestre. 10. Preparar artigos para publicação. 67 O cronograma proposto, a partir de março de 2008 até abril de 2009, pode ser visualizado na Tabela 4 abaixo: Tabela 4: Cronograma de Execução Meses Atividades Mar. Abr. Maio Jun. Jul. Ago. Set. Out. Nov. Dez. Jan. Fev. Mar. Abr. 1 2 3 4 5 6 7 8 9 10 3.5. Resultados Esperados Como resultado, espera-se que sejam identificados e formalizados os Patterns Motivacionais baseados em cores para apoiar os diversos profissionais que atuam no desenvolvimento de projetos Web, no desenvolvimento de sistemas considerando as questões culturais, geográficas, enfim, o senso comum dos usuários, a fim de motivá-los no acesso e no trabalho via Web. Intende-se também que os Patterns Motivacionais formalizados, possam contribuir para o engajamento do usuário no trabalho, em especial o colaborativo, permitir ao usuário uma maior compreensão das informações existentes nos sites dentro de uma organização, como também criar uma comunicação comum entre desenvolvedores de sistemas Web com os usuários. Além disso, espera-se que os resultados obtidos com este trabalho sejam apresentados na forma de publicações e apresentações de artigos em eventos e periódicos da área. E por fim, defender a dissertação no primeiro semestre de 2009. REFERÊNCIAS BIBLIOGRÁFICAS Alexander et al., 1977 Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.; Fiksdahl- King, I.; Angel, S. “A Pattern Language: towns, buildings, construction”. New York: Oxford University Press, 1977, 1171p. Almeida et al., 2003 Almeida, M.; Bax, M. “Uma visão geral sobre ontologias: pesquisa sobre definições, tipos, aplicações, métodos de avaliação e de construção”. Ciência da Informação, Brasília, v.32, n.3, set/dez 2003. Disponível em: http://www.ibict.br/cienciadainformacao/include/getdoc.Php?id=223&article=36&mo de=pdf, Janeiro 2008, pp.7-20. Alpert, 2003 Alpert, S. R. “Getting Organized: Some Outstanding Questions and Issues Regarding Interaction Design Patterns”. In: 20 th CHI – Workshop on Perspectives on HCI Patterns: Concepts and Tools. Fort Lauderdale. Florida, EUA: ACM Press, 2003, 4p. Alves, 1995 Alves, R. A. “Filosofia da Ciência: Introdução ao Jogo e Suas Regras”. São Paulo: Brasiliense, 1995, 21ed., 209p. Anacleto et al., 2006a Anacleto, J. C.; Lieberman, H.; Tsutsumi, M.; Neris, V. P. A.; Carvalho, A. F. P.; Espinosa, J.; Zem-Mascarenhas, S. H.; Godoi, M. S. “Can Common Sense uncover cultural differences in computer applications?”. In: IFIP World Computer Congress - Artificial Intelligence in Theory and Practice. Santiago. New York: Springer-Verlag, v.217, 2006, pp.1-10. Anacleto et al., 2006b Anacleto, J. C.; Lieberman, H.; Carvalho, A. F. P.; Neris, V. P. A.; Godoi, M. S.; Tsutsumi, M.; Espinosa, J.; Talarico Neto, A.; Zem-Mascarenhas, S. H. “Using Common Sense to Recognize Cultural Differences”. In: IberoAmerican Artificial Intelligence Conference/Brazilian Artificial Intelligence Symposium (IBERAMIA/SBIA), Ribeirão Preto. Heidelberg: Springer-Verlag, v.4140, 2006, pp.370-379. Araújo, 2003 Araújo, O. F. N. “Proposta de uma rede de compartilhamento de habilidades no ambiente da Manufatura”. Dissertação de Mestrado, Programa de PósGraduação em Engenharia Mecânica, UNICAMP, 2003, 155 p. Bevan, 1995 Bevan, N. “Usability is quality of use”. In: Anzai & Ogawa (eds) 6th International Conference on Human Computer Interaction. Yokohama. USA: Elsevier, July 1995. Disponível em: http://www.usability.serco.com/ papers/usabis95.pdf, September 2007, 7p. Bevan, 1999 Bevan, N. “Quality in Use: Meeting User Needs for Quality”. Journal of System and Software, v.49, n.1, 1999. Disponível em: http://www.usability.serco.com/papers/qiuse.pdf, August 2007, pp.89-96 Borchers, 2000 Borchers, J. O. “Interaction Design Pattern: Twelve Theses”. In: 17 th CHI Workshop on Pattern Language for Interaction Design. Hague, Holanda, 2000. Disponível em: http://media.informatik.rwth-aachen.de/borchersold/publications/chi2k/CHI2K-Borchers.pdf, January 2008, 6p. Borchers, 2001 Borchers, J. O. “A Pattern Approach to Interaction Design”. John Wiley & Sons, Chichester, UK, March 2001, 264p. Borchers et al., 2001 Borchers, J. O.; Fincher, S; Griffiths, R.; Pemberton, L.; Siemon, E. “Usability pattern language: Creating a community”. AI & Society. v.15, n.4, 2001, pp.377-385. Borgman, 1992 Borgman, C. L. “Cultural Diversity In Interface Design”. In: SIGCHI Bulletin/ACM, v.24, n.4, October 1992, 1p. Buchdid, 2005 Buchdid, S. B. “Investigando a composição de Color Patterns para o Projeto Web: Uma Questão Interdisciplinar”, Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2005, 103p. Buchdid et al., 2005 Buchdid, S. B.; Silveira, L. M.; Silva, J. C. A. “Análise de Aplicação de Cores em Projeto de EAD: Um Estudo de Caso”. In: Simpósio Nacional de Tecnologia e Sociedade, Curitiba: UTFPR, v.1, 2005, pp.1-8. Buchdid, 2006 Buchdid, S. B. “Diagnóstico da Aplicação de Cores em Projetos Web baseado em uma Metodologia”. Dissertação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2006, 113p. Buschmann et al., 1996 Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M. “Patternoriented software architecture: a system of patterns”. Chichester, UK. New York: John Wiley & Sons, 1996, 467p. Carlos, 2007 Carlos, A. J. F. “Aplicando Senso Comum na Edição de Objetos de Aprendizagem”. Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 60p. Carvalho, 2006 Carvalho, A. F. P. “Investigando o Uso de Senso Comum para Apoiar as Práticas de e-Learning”. Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2006, 107p. Carvalho, 2007 Carvalho, A. F. P. “Utilização de Conhecimento de Senso Comum no Planejamento de Ações de Aprendizagem Apoiado por Computador”. Dissertação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 241p. Clear, 2005 Clear, T.; Kassabova, D. "Motivational Patterns in Virtual Team Collaboration". Research and Practice in Information Technology. Australasian Computing Education Conference. Newcastle, Australia, v.2, 2005, 8p. Coplien et al., 1995 Coplien, J. O. “A Generative Development-Process Pattern Language”. In: Pattern Languages of Program Design. Edited by: J. O. Coplien and D. C. Schmidt, Reading EUA: Addison Wesley Longman, 1995, 562p. Coplien et al., 2005 Coplien, J. O.; Harrison, N. B. “Organizational Patterns of Agile Software Development”. Upper Saddle River, NJ: Pearson Prentice Hall, 2005, 2 ed., 432p. Dias, 2000 Dias, C. “Estudo de Caso: idéias importantes e referências”, 2000. Disponível em: www.geocities.com/claudiaad/case_study.pdf, Janeiro 2008, 4p. Falbo et al., 2004 Falbo, R. A.; Ruy, F. B.; Pezzin. J.; Moro, R. D. “Ontologias e Ambientes de Desenvolvimento de Software Semânticos.” In: JIISIC – Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería del Conocimiento, 2004. Disponível em: http://www.inf.ufes.br/~falbo/download/pub/2004-JIISIC1.pdf, Janeiro 2007, 16p. Ferreira, 2007 Ferreira, A. M. “Senso Comum Automatizado para Apoiar a Criação de Jogos Educacionais Contextualizados”. Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 73p. Fincher, 1999 Fincher, S. “What is a Pattern Language?”. In: 16th CHI – The CHI is the Limit. Pittsburgh, EUA: ACM Press. May1999, 2p. Fincher, 2003 Fincher, S. “Perspectives on HCI patterns: concepts and tools (Introducing PLML)”. In: 20th CHI - Conference on Human Factors in Computing Systems. Fort Lauderdale. Florida, USA: ACM Press. September 2003, pp.26-28. Gamma et al., 1995 Gamma, E.; Helm R.; Johnson R.; Vlissides J. “Design Patterns: Elements of Reusable Object-Oriented Software”. Reading, Mass: Addison Wesley Longman, 1995, 431p. Gauch Jr, 2002 Gauch Jr, H. G. “Scientific Method in Practice”. Cambridge (UK): Cambridge University Press, 2002, 1ed., pp.448. Gerstner, 1988 Gerstner, K. Las Formas del Color: La interacción de los elementos visuales. Madrid: Ed. Hermann Blume, 1988, 215p. Gonçalves, 2004 Gonçalves, L. L. “EditWeb: mecanismos de autoria assistida de páginas para ambientes de EAD via Web visando usabilidade e acessibilidade”. Dissertação de Mestrado, Programa de Pós Graduação em Computação, UFRGS, 2004, 235p. Guimarães, 2000 Guimarães, L. “A cor como informação: a construção biofísica, lingüística e cultural da simbologia das cores”. São Paulo: Annablume, 2000, 2 ed., 143p. Haase et al., 2005 Haase, P.; Motik, B. “A Mapping System for the Integration of OWL-DL Ontologies”. In: IHIS – Interoperability of Heterogeneous Information System, 2005, 8p. Jackson et al., 1994 Jackson, R.; MacDonald L.W.; Freeman K. “Computer Generated Color: A Practical Guide to Presentation and Display”. John Wiley & Sons, 1994, 244p. Joly, 1996 Joly, M. “Introdução à Análise da Imagem”. São Paulo: Papirus, 1996, 152p. Lenat et al., 1990 Lenat, D. B.; Guha, R. V.; Pittman, K.; Pratt, D.; Shepherd, M. “Cyc: toward programs with common sense”. In: Communications of the ACM. New York, NY: ACM Press, v.33, n.8, August 1990, 20p. Lieberman et al., 2005 Lieberman H.; Schmandt C. “Common sense reasoning for multi-lingual communication”. Massachusetts: MIT/Media Laboratory Software Agents Group, Internal Document, 2005, 20p. Liu et al., 2002 LIU, H.; SINGH, P. “Makebelieve: Using Commonsense Knowledge to Generate Stories”. In: Eighteenth National Conference on Artificial Intelligence, 2002. Disponível em: http://agents.media.mit.edu/projects/makebelieve/ AAAI2002-makebelieve.pdf, December 2007. 2p. Liu et al., 2004 Liu, H.; Singh P. “ConceptNet: a practical commonsense reasoning toolkit”. BT Technology Journal, v.22, n.4, 2004, pp.211-226. Löwgren, 2005 Löwgren, J. “Inspirational patterns for embodied interaction”. Presented at Nordic Design Research Conference (Nordes), Copenhagem, May 2005, 9p. Lukosch et al., 2007 Lukosch, S.; Schümmer, T.; Jarmer, T. “There’s more than just a Login: Six patterns that make connecting to a collaborative system more convenient”. EuroPlop, 2007. Disponível em: http://hillside.net/europlop/europlop2007/ workshops/B2.pdf, January 2008, 26p. Mahemoff et al., 1998 Mahemoff, M. J.; Johnston, L. J. “Pattern Languages for Usability: An Investigation of Alternative Approaches”. In: APCHI – Asia-pacific conference on human computer interaction. Los Alamitos, EUA: IEEE Computer Society Press, 1998, pp.25-31. Marcus, 2002 Marcus, A. Culture Class vs. Culture Clash. In: Interactions. New York, NY: ACM Press, v.9, n.3, May/June 2002, pp.25-28. Martins et al., 2002 Martins, R. T.; Hasegawa, R.; Nunes, M. G. V. “Curupira: Um Parser Funcional para a Língua Portuguesa”, Relatório Técnico. São Carlos: NILC, 2002, 43p. Meszaros et al., 1996 Meszaros G.; Doble J. “Metapatterns: A pattern language for pattern writing”. In: 3rd Pattern Languages of Programming Conference, Monticello, Illinois. September 1996. Disponível em: http://www.laputan.org/pub/papers/ Metapatterns.rtf, December 2007, 37p. Montero et al., 2002 Montero, F.; Lozano, M.; González, P.; Ramos, I. “A First Approach to Design Web Sites By Using Patterns”. In: First Nordic conference on Pattern Languages of Programs: VikingPLoP. Hojstrupgard, Denmark. September 2002, pp.137-158. Mueller, 1998 Mueller, E. T. “Natural language processing with ThoughtTreasure”. New York: Signiform, 1998, 343p. Muniz, 2004 Muniz, M. C. M. “A construção de recursos linguistic-computacionais para o português do Brasil: o projeto Unitex-PB”. Dissertação de Mestrado, Programa de Pós Graduação em Ciências da Computação e Matemática Computacional, ICMC-USP, 2004, 92p. Nielsen, 1993 Nielsen, J. “Usability Engineering”. San Francisco: Morgan Kaufmann. September 1993, 362p. Olsina et al., 1999 Olsina, L.; Godoy, D.; Lafuente G.J.; Rossi G. “Specifying Quality Characteristics and Attributes for Websites”. In: First ICSE – Workshop on Web Engineering, Los Angeles, USA. May 1999, p.266-278. Pastoreau, 1997 Pastoreau, M. “Dicionário das cores do nosso tempo”. Lisboa: Editorial Estampa, 1997, 188p. Pedrosa et al., 2005 Pedrosa, T. M. C. P.; Toutain, L.B. “O Uso das Cores como informação em Interfaces Digitais”. In: VI Cinform – Encontro Nacional de Ciência da Informação: Informação, Conhecimento e Sociedade Digital. Salvador-BA. 2005, 10p. Pereira, 2007 Pereira, E. N. “Investigando o uso de senso comum no apoio e contextualização de atividades educacionais baseadas em jogos”. Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 79p. Pintores Famosos, 2000 Pintores Famosos A arte na Internet. “Kandinsky”, 2000. Disponível em: http://www.pintoresfamosos.com.br/?pg=kandinsky, Janeiro de 2008. Pontes et al., 2008 Pontes, A.; Guimarães, A. S.; Cossenza, A. L.; Rodrigues, M. P.; Boddeker, L.; Donner, C. “Motivação”. Introdução à Administração. Curso de Graduação em Ciências Atuariais. Universidade Estácio de Sá. Disponível em: www.estacio.br/graduacao/cienciasatuariais/artigos/trab_motivacao.pdf, Janeiro 2008, 56p. Pressman, 2006 Pressman, R. S. “Engenharia de Software”. São Paulo: McGraw-Hill, 2006, 6 ed., 710p. Quináia, 2005 Quináia, M. A. “Contribuição a uma Metodologia para Identificação de Padrões Arquiteturais de Software”. Tese de Doutorado, Programa de Engenharia Elétrica e Informática Industrial, UTFPR, 2005. 141p. Rihle et al., 1996 Rihle, D.; Züllighoven, H. “Understanding and Using Patterns in Software Development”. In: Theory and Practice of Object Systems. Boston, v.2, n.1, 1996, p.3-13. Rousseau, 1980 Rousseau, René-Lucien. “Linguagem das cores: energia, simbolismo, vibrações e ciclos das estruturas coloridas”. Tradução J. Constantino K. Riemma. São Paulo: Pensamento, 2 ed.,1980, 191p. Salviano, 1997 Salviano, C. F. “Introdução à Software Patterns”. In: XI SBES – Simpósio Brasileiro de Engenharia de Software. Fortaleza, CE, 1997. Disponível em: ftp://st.cs.uiuc.edu/pub/patterns/presentations/nswpatt.doc, Novembro 2007, 22p. Schümmer et al., 2007a Schümmer, T.; Tandler, P. “Patterns for Computer-Mediated Interaction”. Disponível em: http://moskau.pi6.fernuni-hagen.de:3000/, September 2007. Schümmer Schümmer, T.; Lukosch, S. “Patterns for Technology Enhanced Meetings”. et al., 2007b Disponível em: http://moskau.pi6.fernuni-hagen.de:3000/, September 2007. Silva, 2005 Silva, A. C. “Aplicabilidade de Padrões de Engenharia de Software e de Interação Humano-Computador no Processo de Desenvolvimento de Sistemas Interativos”. Qualificação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 81p. Silveira, 2002 Silveira, L. M. “A Percepção da Cor na Imagem Fotográfica em Preto-eBranco”. Tese de Doutorado, Programa de Pós-Graduação em Comunicação e Semiótica, PUC-SP, 2002, 311p. Silveira et al., 2004 Silveira, L. M.; Silva, J. C. A.; Buchdid, S. B. “Color Patterns no Projeto WEB”. In: Webmedia & LA-WEB Joint Conference, Ribeirão Preto, v.2, 2004, pp.1-8. Silveira et al., 2005 Silveira, L. M.; Buchdid, S. B.; Silva, J. C. A. “Metodologia de Aplicação de Cores no Projeto WEB”. In: XI WebMedia – Web e Multimídia: Desafios e Soluções. Poços de Caldas, 2005, pp.97-126. Singh, 2002 Singh, P. “The OpenMind Commonsense project”. Massachusetts: MIT/Media Laboratory Software Agents Group, January 2002. Disponível em: http://web.media.mit.edu/~push/OMCSProject.pdf, December 2007, 12p. Sun, 2001 Sun, H. “Building A Culturally-Competent Corporate Web Site: An Exploratory Study of Cultural Markers In Multilingual Web Design”. In: International Conference on Computer Documentation. 2001, 8p. Talarico Neto et al., 2004 Talarico Neto, A.; Silva, A. C.; Silva, J. C. A.; Penteado, R. A. D. “Padrões de Interação – O Contexto WEB”. In: IHC: Mediando e Transformando o Cotidiano, 2004, 22p. Talarico Neto et al., 2006 Talarico Neto, A.; Anacleto, J. C.; Neris, V. P. A.; Godoi, M. S.; Carvalho, A. F. “Framework baseado na Linguagem de Padrões Cog-Learn para apoio a criação de objetos de aprendizagem”. In: XII WebMedia – Simpósio Brasileiro de Sistemas Multimídia e Web, Natal, 2006, pp.128-137. Tidwell, 1999 Tidwell, J. “Common Ground: A Pattern Language for Human-Computer Interface Design”, 1999. Disponível em: http://www.mit.edu/ ~jtidwell/interaction_patterns.html, January 2008. Tsutsumi, 2006 Tsutsumi, M. “Uso do Senso Comum na detecção de diferenças culturais no contexto do Projeto OpenMind CommonSense no Brasil”. Dissertação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2006, 113p. Uschold et al., 2004 Vlissides, 1996 Uschold, M.; Grüninger, M. “Ontologies and Semantics for Seamless Connectivity”. SIGMOD Record, v. 33, n. 4, 2004, pp.58-64. Vlissides, J. “Pattern hatching: Seven habits of successful pattern writers”. In: C++ Report, November/December 1996. Disponível em: http://www.research.ibm.com/designpatterns/pubs/7habits.html, December 2007. Yaguinuma, 2007 Yaguinuma, C. A. “Sistema FOQuE para Expansão Semântica de Consultas baseada em Ontologias Difusas”. Dissertação de Mestrado, Programa de Pós Graduação em Ciência da Computação, UFSCar, 2007, 111p. Yin, 2002 Yin, R. K. “Case Study Research. Design and Methods”. California (USA): Sage Publications, Applied social research method series, 2002, v.5, 3ed., 200p. Welie et al., 2003 Welie M. van; Veer, G. C. van der. “Pattern Languages in Interaction Design: Structure and Organization”. In: Interact. September 2003, pp.527-534.