exame de qualificação - LabES

Transcrição

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
McDonald’s
Ferrari
M, 18_29, superior_incompleto, Florianópolis, SC
Tomate
M, 30_45, superior_completo, Rio de Janeiro, RJ
Cereja
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
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
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
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.

exame de qualificação - LabES

Transcrição

Documentos relacionados

Pattern Magic. Tecidos elásticos

Guitar x - No Dia-a-Dia do Guitarrista!

trabalho “5s” - bourbon café - UFBA

Newsletter - GETH – Grupo de Estudos de Tumores Hereditários

A filosofia da ciência de Rubem Alves O senso comum e a ciência

LEITURA COMPARTILHADA T5 Caros Pais, No dia 08/10

Edital de Atividades Compl. 2-2016 – ativ. complementares

Jack-O`-Lanterns - Escola Básica e Secundária Mouzinho da Silveira

julho - Festival Estoril Lisboa

A Alma de Homer- A Psicologia de “Os Simpsons”