Configuração de Disponibilização do Sistema

Com respeito à configuração utilizada para disponibilização da aplicação TRIP (

deployment

da solução), foram cobertas as principais zonas do DSI, ou seja, Secretaria e principais locais de frequência dos alunos: LAP1 (Lab. Actividades Pedagógicas 1) e Gabinete Apoio aos Laboratórios. Por ser uma sala com acesso restrito, o LID3 (Lab. de Investigação e Desenvolvimento) foi utilizado como local para manter o servidor principal do protótipo, ou seja, onde estava a base de dados, o servidor

web

e o ambiente de

scripting

em execução.

O projecto foi inicialmente idealizado para uma implementação abrangente a todo o edifício, ou mesmo ao

campus

universitário. Contudo, devido a diversos constrangimentos de ordem técnica e burocrática, foi circunscrito a uma área mais reduzida, o DSI. Não obstante, com os recursos disponibilizados, tornava-se ainda mais premente a necessidade de ponderar os espaços mais críticos para dar alguma cobertura com impacto suficiente em termos de utilidade.

Foram colocados três cartazes, ver Ilustração 31, alusivos ao projecto que demarcavam, concomitantemente, as zonas onde haveria cobertura

bluetooth

para utilização da aplicação. Um cartaz em cada uma das três zonas já referidas, onde existia um TripServer a funcionar.

Ilustração 31 – Cartaz do Projecto TRIP - Zona TRIP

Foram utilizados quatro PC’s com sistema operativo Windows XP Professional, Service Pack 2 e ambiente de execução Java (Java2 Runtime Environment 1.5.0-6). Era necessário este sistema operativo por ser, na altura, o único que implementava a necessária pilha protocolar de

bluetooth

(Microsoft Bluetooth Stack) sem quaisquer custos adicionais. Esta pilha era referenciada pelas componentes do TripServer para suportar a comunicação com os clientes (através do perfil OBEX). De forma idêntica, o ambiente Java era necessário para suportar as componentes do “servidor aplicacional” (TripListener e TripPusher) desenvolvidos nessa linguagem. Para além disto, dependendo do tipo de função que cada posto cumpria, possuíam

software

adicional conforme o papel desempenhado como de seguida se descreve.

3.1.7.1 Servidor Tourém

Tourém foi o nome do PC que teve o papel de “servidor principal”, localizado numa sala de acesso restrito, o Laboratório de Investigação e Desenvolvimento (LID) 3. Neste, estava instalado todo o

software

de

backoffice

para suporte ao projecto. Sendo um Pentium4 a 1.7Ghz com 512Mb de memória, configurado com o IP (Internet Protocol) 193.137.8.88 e o identificador de

bluetooth

PT000949_1, continha as seguintes aplicações:

• MySQL Server 5.0 e phpMyAdmin 2.6.4 – aplicações para suportar a base de dados. O phpMyAdmin apenas foi utilizado como forma de facilitar o acesso e disponibilização (

deployment

) de novas

releases

remotamente.

• Portal Situaction 1.0 – aplicação desenvolvida no DSI, orientada à gestão de eventos (EQUIP), com funcionalidades de suporte para ecrãs públicos. O projecto utilizou a API que permitia o envio de tuplos para serem consumidos por essa aplicação e, assim, enviar mensagens dos utilizadores para alguns dos ecrãs públicos disponibilizados neste projecto- piloto.

• ImageMagick 6.2.8 e Python 2.4.3 – aplicações que suportavam os

scripts

de geração de novos

tripcodes

. Os autores deste tipo de

ringcodes

disponibilizaram a funcionalidade de gerar novas

tags

na linguagem Python, cujo

output

era um documento com extensão PS (Postscript). Foi necessário recorrer às bibliotecas do ImageMagick para assim converter numa imagem, neste caso GIF, de forma a facilmente ser incorporada (exibida e impressa) no

site

do projecto.

• Internet Information Services (IIS) 5.1 e Microsoft .NET Framework 2.0 – O

site

de promoção e

backoffice

do projecto foi desenvolvido em Microsoft VB.Net 2005 requerendo, por isso, a Framework 2.0 e o servidor de páginas

web

da Microsoft.

• RealVNC 4.1 e Remote Desktop – estas aplicações/serviços permitiam o acesso remoto às máquinas. O serviço de Remote Desktop foi activado apenas nesta máquina para permitir o acesso remoto do exterior e o VNC controlava as restantes máquinas do projecto a partir do acesso a esta. Ao contrário do Remote Desktop, o VNC foi utilizado por não criar uma nova sessão e esconder/fechar a activa na máquina de destino. Desta forma, ao sair da máquina destino, mantinha os serviços (de ecrã público) visíveis e a correr tal como estavam.

• TripListener e TripPusher – Embora inicialmente também implementados nesta máquina, constatou-se que, por inadequação do

dongle

bluetooth

(baixo alcance) ou local de passagem de alunos pouco frequente, a sua utilização não estava a ser verificada. E, uma vez que pelo papel que desempenhava, a prioridade desta máquina seria responder às solicitações que possuía dos outros servidores, optou-se por se desactivar estas aplicações neste PC.

Por estar apenas a suportar funções de

background

, estar num local onde não circulavam com regularidade elementos da população definida, nesta zona não existiam quaisquer

tripcodes

afixados ou ecrã público.

3.1.7.2 Servidor Soajo

O Soajo foi a máquina colocada na sala dos alunos, Laboratório de Actividades Pedagógicas (LAP) 1, sendo um Celeron a 2.4Ghz com 256 Mb de memória. Por razões de localização física, ficou conectada numa outra rede administrativa, com um IP dinâmico (DHCP), e identificador de

bluetooth

PT000949_2, contendo as seguintes aplicações:

• TripPusher; • TripListener;

• Portal Situaction – Como já referido, usufruindo do API disponibilizado por esta aplicação (EQUIP, Internet Explorer Player, entre outros componentes), foi implementada a funcionalidade de visualização de conteúdos dinâmicos em ecrãs públicos. Assim sendo, no ecrã deste PC – designado por “Ecrã LAP1” surgiam mensagens públicas aos utilizadores, conteúdos do

site

, tal como sondagens activas, descrições das funcionalidades da aplicação TRIP e

tripcodes

que poderiam ser “picados” pelos TripReaders a fim de usufruir de determinado serviço.

Pelo facto de se encontrar numa sala de livre acesso e sem supervisão, tentou proteger-se o equipamento, sendo para esse efeito utilizada uma caixa em madeira, onde o PC se encontrava resguardado, como se pode constatar na Ilustração 28.

Aqui, por ser um local onde os alunos estão com muita frequência, foram colocados, para além de um ecrã público, pelo menos, um exemplar de cada um dos serviços disponíveis. De notar que serviços como o “Mais informações” e o “Participar na sondagem” têm um código por cada item que identificam. No total, só nesta sala, foram colocados inicialmente cerca de 30

tripcodes

afixados nas várias paredes. Para além disso, no período inicial, foram colocados alguns panfletos dispersos pelas mesas contendo informação sobre o projecto e

tripcodes

.

3.1.7.3 Servidor Xertelo

O Xertelo foi a máquina colocada numa das extremidades do corredor do DSI, no Gabinete de Apoio aos Laboratórios, sendo um Pentium3, com 256 Mb de memória que não estava exclusivamente dedicado a este projecto, contendo por isso outras aplicações em execução. Com o IP 193.137.8.74 e com o identificador de

bluetooth

PT000949_4, este foi utilizado devido à sua localização estratégica e à possibilidade de projectar conteúdos numa tela de grandes dimensões colocada na divisória desse gabinete. Neste caso, as aplicações em execução, com relevância para o projecto, eram as seguintes:

• TripListener;

• Portal Situaction – Utilizando um projector como ecrã público, designado por “Tela Serv. Inf.”, possibilitou a apresentação apenas de conteúdos do

site

, uma vez que as câmaras fotográficas dos dispositivos em questão não conseguiam fotografar correctamente os

tripcodes

aqui projectados.

Ilustração 33 – Projector do ecrã público "Tela Serv. Inf."

O TripPusher foi desactivado nesta máquina por interferir com outros projectos a decorrer, sobrecarregando em demasia o dispositivo de

bluetooth

, impedindo a sua utilização, até mesmo pelo componente TripListener.

Como se pode verificar pela Ilustração 33, embora estivesse num local privilegiado de passagem, mas por não se pretender a afixação excessiva de símbolos nos gabinetes de terceiros, apenas foi colocado um

tripcode

“Anunciar” para assim permitir interagir com a tela que ali se encontrava.

3.1.7.4 Servidor Lindoso

O Lindoso foi a máquina colocada na outra extremidade do DSI, na Secretaria do Departamento, sendo um pentium3, com 256Mb de memória com o IP 193.137.8.79 e com o identificador de

bluetooth

definido como PT000949_3. As aplicações em execução eram a seguintes:

• TripReader; • TripPusher;

• Portal Situaction – Usufruindo da excelente localização do ecrã público (na porta da entrada da Secretaria e ao nível dos membros superiores), designado na aplicação por “Ecrã Secretaria DSI”, exibia as mensagens públicas dos utilizadores, promovia as funcionalidades da aplicação TRIP e permitia a leitura directa de

tripcodes

para executar determinada funcionalidade.

Ilustração 34 – Ecrã público na Secretaria do DSI

Uma vez que a passagem de alunos por esta área não era frequente, o Lindoso funcionou, sobretudo, como um instrumento dinamizador e promotor da experiência, e não tanto como meio de interacção.

Pela mesma razão que no espaço anterior, apenas se colocou um

tripcode

“Anunciar” para interacção com o ecrã público aí existente.

3.1.7.5 Divulgação do Projecto

Este projecto foi aberto a qualquer aluno do DSI que se encontrasse motivado a utilizar o sistema, sem que tenha sido utilizado qualquer meio de persuasão ou fornecida qualquer contrapartida. Não foi efectuada qualquer sessão de esclarecimento, formação ou qualquer outro tipo de iniciativa que pudesse influenciar a participação. O único estímulo resumiu-se à divulgação da experiência através de:

• Afixação de cartazes53 nos vários locais onde os serviços estavam disponíveis, a que se denominou por zonas de cobertura;

53

• Três ecrãs públicos que publicitavam as funcionalidades do projecto, sondagens e mensagens públicas;

• Envio de um

e-mail

genérico aos delegados de turma dos vários anos do curso de Informática54

a oficializar o arranque do projecto;

• Afixação dos próprios

tripcodes

nos locais onde os serviços estiveram disponíveis (Ilustração 35 e Ilustração 36);

Ilustração 35 – Tripcodes afixados numa das zonas de cobertura

Ilustração 36 – Zona de cobertura – sala LAP1

• Utilização de um mecanismo de

push

para disseminar automaticamente a aplicação; • Alguns panfletos distribuídos numa das salas com maior adesão por parte dos potenciais

utilizadores (LAP1), publicitando o projecto, os códigos e o

site

.

• Apenas foi disponibilizado um telemóvel de teste confiado a um voluntário, colaborador nos testes aplicacionais e na promoção da iniciativa. Para os restantes casos, os utilizadores teriam de confiar na aplicação e instala-la nos seus dispositivos.

A duração do projecto, inicialmente prevista para dois meses, prorrogou-se até aos três meses. Tal situação deve-se a dois factos: primeiro, a participação não foi tão significativa quanto o previsto; segundo, o prazo de realização do projecto coincidiu com um período de férias logo após duas semanas do início oficial do mesmo. Embora o plano de implementação55 _{tivesse sido cumprido,}

houve necessidade de flexibilizar alguns prazos para contornar questões puramente técnicas e de logística.

Durante o período de avaliação do protótipo, pretendeu proporcionar-se aos potenciais utilizadores:

54 _{Ver Anexo C – E-mails da Equipa do Projecto TRIP.} 55

• Um leque alargado de funcionalidades, seguindo os critérios definidos da abordagem proposta na secção 1.2);

• A disponibilização de um único programa para reconhecimento dos códigos, para, deste modo, evitar a necessidade dos clientes contactarem com diferentes instalações e, consequentemente, de saberem que programa utilizar para picar cada tipo de código bem como outras adversidades daí recorrentes.

No documento A adopção de códigos visuais como modelo de interacção (páginas 75-83)