SERVIÇO DE BIHETES DIITAIS PARA OS TRANSPORTES …jcardoso/Services/Concord/bTicket-Service... ·...

SERVIÇO DE INTERNET B-TICKET | 1

SERVIÇO DE BILHETES DIGITAIS PARA OS TRANSPORTES SMTUC

2 | INTERACÇÃO HUMANO COMPUTADOR SERVIÇO DE INTERNET B-TICKET | 3

FICHA TÉCNICA

O presente trabalho insere-se na disciplina Interacção Humano Computador leccionada no Departamento de Engenharia Informática da Universidade de Coimbra.

Jorge Cardoso (Supervisor)Associate [email protected]

O projecto representa o trabalho prático global desenvolvido durante o semestre, sob o método de metas periódicas. Encontra-se em desenvolvimento em regime de projecto de grupo pelos alunos:

Cátia CostaMestrado em Design Multimédia [email protected]

João Casalta NabaisMestrado em Engenharia Informá[email protected]

Luís Alte da VeigaMestrado em Engenharia Informá[email protected]

Pedro MacedoMestrado em Engenharia Informá[email protected]

Pedro VazMestrado em Design Multimá[email protected]


4747

56

68

8585

88

Avaliação da interface11.1 – Self-Service Introspection Survey (SSIS)

11.2- Avaliação Heurística

11

Protótipo do Sistema9.1- Cenário Expandido & Storyboard

9.2- Sketches

9.3- Hight Fidelity Prototype

9Introdução do projecto 4

INDICE

Tarefas e Objectivos 6

3232

36

38

Limitações das Soluções Actuais 7

4040

44

Brainstorming 8

Perspectiva do Negócio

Tarefas7.1 - Análise de Tarefas

7.2- Cenário

7.3- Requisitos

10

Caracterização dos Utilizadores6.1 - Estratégia de Investigação

6.2 - Tipos de Utentes

6.3 - Tabela de Caracterização de Utentes

6.4 - Entrevistas aos Utentes

6.5 - Personas

Análise do Serviço8.1 - Serviço como um sistema

8.2- Service Blueprinting

1214

16

20

22

27

1

2

3

4

5

7

6

8

8373

74

76

Implementação do Serviço10.1- Framework MVC

10.2- Tarefas — Página Web

10.3- Opções de design — Página Web

10

94

96

Revisão Crítica

Conclusão

12

13


Utilizar os transportes públicos em Coimbra é uma realidade que abrange grande parte da população, estudantes, trabalhadores, reformados, turistas, etc. , todos vêm neste modelo de transporte um método eficaz e económico de se deslocarem na cidade.Contudo, o processo de aquisição de bilhetes e a sua validação ao iniciar a viagem não apresentam melhorias significativas há largos anos.

O projecto bTicket pretende redefinir este processo, valendo-se das capacidades dos novos sistemas informáticos para conseguir simplificar o processo e alargar o seu espectro de utilização aos novos modelos digitais.

O sistema, apresenta-se como um serviço web (ISS - Internet-based Self-Service), que pretende solucionar dois problemas num só serviço:

• Primeiro a compra de bilhetes individuais, livros de viagem e validação de passes mensais.

• Seguidamente o processo de validação de viagens na viatura dos SMTUC, num sistema prático, digital e seguro, conseguido pela atribuição de um QR Code (Quick Response Code).

A plataforma a desenvolver, comporta-se como uma loja virtual, de venda e prestação de serviços, onde os utentes podem aceder para a aquisição de viagens mas igualmente para acederem a informações sobre o serviço de transportes, como horários e percursos das viaturas.

INTRODUÇÃO DO PROJECTO1


A plataforma de serviço bTicket, prestará ao utente um conjunto de funções muito objectivo. Pretende-se conseguir chegar ao maior número de utilizadores possível, tendo para isso de oferecer um serviço simples, rápido e seguro. Para conseguir atingir estes propósitos tanto o processo de gestão: a aquisição e pagamentos, como a validação na viatura dos bilhetes, devem ser desenvolvidos de modo a facilitar o serviço e gerar confiança por parte do utente no novo sistema.

Manutenção da conta bTicket - criar e efectuar alterações nos dados da respectiva conta.

Aquisição/Compra de viagens de autocarro - efectuar pagamento e receber respectivo QR Code de uma das seguintes maneiras:• MMS - Um modelo de utilização para utentes que não possuam um dispositivo

móvel capaz de receber emails.• Email - O modelo de e-mail será o sistema padrão, porque permite um numero de

dados mais detalhados.• Papel - Este modelo garante que utentes que não disponham de nenhum meio

digital para usar o seu bilhete, possam comprar o bilhete a partir de casa e imprimi-lo para o usar em formato físico.

Consultar saldo de viagens - caso o utente compre um QR Code de mais do que uma viagem, será possível consultar no serviço quantas viagens ainda tem.

Consultar horários de autocarros - visualizar os diferentes horários de todos os autocarros da rede SMTUC.

Consultar itinerários de autocarros - visualizar os itinerários de todos os autocarros da rede SMTUC.

Recuperar QR Code - se o utente perder o seu QR Code e ainda não tiver usufruído de todas as suas viagens, é-lhe permitido recuperar esse mesmo QR Code.

Hoje em dia, as soluções oferecidas pelos serviços SMTUC exigem que o utente se desloque fisicamente a um balcão ou máquina para comprar viagens, quer na forma de senha quer na forma de passe. Caso o utente não tenha consigo viagens na altura em que pretende viajar, a única solução actual é a de comprar, por um valor superior, uma viagem no próprio autocarro junto do condutor, o que provoca um atraso na partida do autocarro.

A nossa solução visa que não seja necessária a deslocação por parte dos utentes de forma a adquirirem as respectivas viagens, tal como evitar que tenham de comprar viagens junto do condutor do autocarro. Assim sendo, através de uma plataforma Web, os utentes podem comprar viagens e receber esta sob a forma de QR Code e utilizá-la de uma forma simples quando iniciarem a sua viagem, pois basta passar o QR Code pelo leitor e a sua viagem é automaticamente validada.Por fim, visto que estamos numa era onde grande parte da população tem dispositivos móveis com acesso à Internet, esta solução torna o processo de compra e utilização mais ágil.

TAREFAS E OBJECTIVOS LIMITAÇÕES DAS SOLUÇÕES ACTUAIS2 3

Antes de chegar ao presente conceito da bTicket, existiu no grupo de trabalho a preocupação de debater ideias e apontar problemas na estrutura social. Houve o objectivo claro de, recorrendo ao desenvolvimento de um serviço inovador ou à redefinição de um sistema existente, poder desenvolver uma ferramenta capaz de melhorar significativamente a qualidade de vida social, tornando os processos mais simples, mais intuitivos e funcionais.

Serviço de restauração - plataforma que permitiria ao cliente reservar uma mesa, agendar pedidos, consultar ementa e preçário.

Sistema de informação para farmácias - efectuar comparação de fármacos e ter a possibilidade de propor ao médico alguns genéricos.

Plataforma de bilheteira única - plataforma de venda de bilhetes centralizada, isto é, comprar bilhetes para diferentes tipos de eventos, nomeadamente, desporto, cinema, música, dança, cinema, teatro, etc.

Sistema de apoio a idosos e paliativos - apoio doméstico, social e médico para combater a solidão existente na terceira idade, o que permitiria, de certa forma, um acompanhamento melhorado destes idosos, mesmo à distância.

Loja do Cidadão - reorganização do serviço de tiragem de senhas da Loja do Cidadão, tendo como objectivo torná-lo mais intuitivo e, desta forma, ajudar os utentes a ter uma melhor orientação quanto ao que pretendem efectuar quando se deslocam a este estabelecimento.

Lista de Supermercado - Desenvolver uma lista de supermercado, independente de uma marca especifica e completamente gerida pelo utilizador. Na aplicação, recorrendo ao GPS do telemóvel, o utilizador marcaria o sitio de onde retirou o produto, ao longo do tempo, estes dados serviam tanto para construir uma lista baseada na periocidade, como um percurso eficiente servindo-se das localizações inseridas.

BRAINSTORMING4



Um serviço, só se torna verdadeiramente útil quando o seu potencial utilizador identifica claramente a sua função, reconhecendo de alguma forma as mais valias que este oferece em relação a um serviço anteriormente estabelecido. Cada individuo é único, e como tal, interpreta a informação consoante o seu background de experiências. Neste sentido, para evitar o risco de rejeição, o serviço tem de ser claramente apresentado e publicitado e a marca tem de ser reconhecida pelos utentes como algo familiar de maneira a formar uma ideia homogénea pela maior parte do público.O planeamento de negócio do serviço, está à partida, condicionado pela empresa de transportes onde seria implementado (neste caso os SMTUC), pelo que qualquer estratégia de venda tem implícito tanto os preços que a transportadora

PERSPECTIVA DO NEGÓCIO5

efectua pelas suas viagens, como pelos modelos que estruturam as viagens, nomeadamente, descontos especiais a estudantes e idosos, estrutura das viagens, bilhete diário único, passe mensal, etc.Para o serviço bTicket, as normas da empresa devem ter um tratamento igual às praticadas actualmente, deixando apenas espaço para explorar hipoteticamente condições de promoção para encorajar a aderência ao novo serviço, ou vantagens acumuladas ao atingir determinado número de viagens efectuadas.

ParticipantesFornecedores - bTicket Team;Consumidores - utentes de autocarros SMTUC;Parceiros - Universidade de Coimbra, SMTUC e Câmara Municipal de Coimbra.

Nível do ServiçoPerformance - tempo de espera pelo utente para receber confirmação de compra entre 3 e 5 segundos; tempo de execução do serviço de compra deve ser em média 3 minutos;Confiabilidade - serviço sempre disponível e métodos tradicionais de pagamento;Segurança - autenticação necessária para usar o serviço; mecanismos de encriptação; integridade e confidencialidade dos dados;Rating - serviço comunitário de rating que permite avaliar o nosso serviço numa escala de 1 a 5.

MarketingPreço - moeda utilizada é o Euro; preço flutuante consoante o número de viagens que se comprar, taxado a 6% de imposto, sendo que o pagamento pode ser efectuado por VISA ou MasterCard;Documentação• Interna - folhetos informativos a descrever o serviço; tutoriais online de

utilização do serviço; relatórios e documentos de desenvolvimento;• Externa - horários e itinerários produzidos pelos SMTUC;• Mercado - facturas e talões de pagamentos.

Leis e Cláusulas - secção no serviço Web que contém os Termos de Utilização: normas, obrigações e penalizações.


CARACTERIzAÇÃO DOS UTILIzADORES6

Os SMTUC, são de todos e para todos. Uns viajam porque têm de ir para a escola todas as manhãs, outros porque vendem fruta no Mercado, outros porque não gostam de conduzir na confusão do trânsito, outros porque andam a conhecer a zona histórica da cidade. São muitos os utilizadores dos serviços, conhece-los é conhecer as suas necessidades. Desenvolver um serviço que lida directamente com um grande número de utilizadores apresenta características fundamentais ao sucesso da implementação que não podem ser alienadas. Conhecer o público e identificar as suas qualidades é uma das orientações base mais importantes para o desenvolvimento da aplicação.


Para traçar um quadro conclusivo na investigação dos utentes, é imperativo fazer três perguntas essenciais para definir esse público: “Quem, como e porquê?” Ao serem identificadas estas respostas encontram-se os utilizadores modelo dos serviços de transporte, esta análise permite, que ao ser desenhado, o serviço não perca de vista os objectivos a que se propõe: resolver os problemas específicos do maior número de utentes possível e encontrar soluções que estejam acessíveis à grande maioria.

QUEM?Encontrar os utilizadores é um primeiro passo da investigação. No caso do serviço bTicket, esse facto é bastante explícito, pois o projecto é desenhado para o serviço de transportes prestado à comunidade de Coimbra. Para um estudo assertivo, os estudos seriam recolhidos directamente junto dos utentes dos transportes durante a sua utilização. Neste sentido, inclui-se três situações distintas: durante o uso dos transportes, nas situações de espera nas paragens e, finalmente, junto dos postos de venda de bilhetes e renovação de passes.

COMO?Identificar o modo como os utentes usam os transportes é primordial para desenhar o serviço, mas principalmente para encontrar os perfis de utentes diferentes. Um numero tão vasto de utentes, como no caso dos SMTUC, implica directamente que existam classes distintas. Para as encontrar, a investigação seria repartida de forma homogénea, tanto geograficamente, recolhendo amostras de diferentes zonas da cidade: junto de escolas, zonas residenciais, zonas de serviços e compras, zonas históricas e de turismo; bem como de zonas mais periféricas à cidade.A segunda distribuição seria temporal, nomeadamente para recolher dados referentes a picos de utilização, os géneros associados a determinadas horas do dia e mesmo a diferenciação entre os dias da semana.Este levantamento homogéneo, conseguido com uma amostra significativa de inquéritos (cerca de 100 a 200), seria suficiente para apresentar de forma segura os dados que apresentamos seguidamente.

PORQUê?A terceira questão não é algo a que se possa definir uma estratégia prévia. A razão que leva os utentes de Coimbra a usar os transportes não se mede por factores de mercado, concorrência ou tendências, mas deve-se fundamentalmente a factores sociais, económicos e geográficos. Neste sentido, só na conclusão directa da resposta a cada entrevista, se poderiam traçar as razões principais do uso do serviço, que teriam um factor decisivo na estratificação dos utentes. Compreensivamente, a razão que leva um jovem a usar o serviço, não são os mesmos de um idoso, ou de um turista.

ESTRATÉGIA DE INVESTIGAçãO6.1


Idade

Desconto especial

Limitações Físicas

Mobilidade e uso do serviço

Experiência com Sistemas Informáticos

Idade

Desconto especial




Numa fictícia avaliação feita aos utentes dos transportes SMTUC, foram identificadas características distintas que permitem uma estratificação por cinco géneros: estudantes, utentes regulares, idosos, deficientes motores e turistas. Como podemos constatar no gráfico em baixo, a amostra recolhida nas entrevistas apresentaria, depois de definidos os géneros, quantidades distintas que cada um tem na globalidade dos utentes. Essa média global serve essencialmente para se trabalharem medidas que abranjam as necessidades globais mas tendo como factores prioritários as características dos géneros mais frequentes. Os seguintes parâmetros de avaliação representam a síntese de uma avaliação mais pormenorizada (ver pág: 20) que foi retirada directamente das entrevistas a utentes a fim de calcular as médias ( ) apresentadas. No exemplo avaliativo de “mobilidade e uso do serviço” estão referidas, quantitativamente, o uso dos transportes, bem como a capacidade do utente de se deslocar entre as paragens e os locais de interesse.

Estudantes

Utentes regulares

18 ANOS

46 ANOS

89 %

11 %

8 %

16 %

82 %

58 %

77 %

53 %

TIPOS DE UTENTES6.2Os estudantes são o maior género de utentes dos serviços. Caracterizam-se por ser um grupo maioritariamente jovem, com dinamismo e interesse pelas novas tecnologias. A maioria aufere de passe especial. Embora usem apenas algumas rotas muito determinadas (escola/casa), fazem-no com bastante frequência.

Esta é a segunda maior classe, onde se incluem todos os adultos activos que usem os transportes, desde a trabalhadores, desempregados ou outros que se incluem na classe activa fora das características de desconto. Este género demonstra uma boa capacidade física e disposição para aprender novas tecnologias.


Idade

Desconto especial




Idade

Desconto especial




Deficientes motores

Turistas e utentes ocasionais

34 ANOS

38 ANOS

93 %

2 %

78 %

9 %

28 %

42 %

63 %

48 %

Idade

Desconto especial




Idosos

67 ANOS

54 %

36 %

32 %

16 %

Os utentes da terceira idade que usam os transportes, caracterizam-se por ter uma vida ainda bastante activa, sejam eles reformados ou ainda com actividade profissional. No entanto, esta classe apresenta capacidades motoras relativamente baixas e pouco interesse por novos sistemas informáticos.

Esta classe inclui na verdade qualquer utente que tenha alguma espécie de limitação, desde deficientes motores a invisuais, surdos, ou outro género de característica redutora das capacidades perceptivas. Apresentam, por outro lado, um significativo interesse e força de vontade em aprender processos que lhe dêem autonomia.

Na ultima classe são incluídos todos os utentes ocasionais, aqueles que menos estão ambientados com o processo de utilização. Dentro deles incluem-se os turistas, estrangeiros ou nacionais, ou utentes esporádicos irregulares. Neste sentido apresentam grande mobilidade física e grande curiosidade pelo meio que o rodeia.


TABELA DE CARACTERIZAçãO DE UTENTES6.3

TIPO de uTenTe nOMe GÉneRO IdAde PROFISSÃOdeSCOnTO

eSPeCIALIdIOMA

LIMITAÇÕeS

FÍSICAS

VIATuRA

PeSSOAL

LOC. GeO. à

bILheTeIRA

FAVORáVeL

LOC. GeO. A

PARAGeM

FAVORáVeL

nº VIAGenS

POR dIA

PeRÍOdO

dO dIA

dIAS de

VIAGeM

ATITude eXPeRIÊnCIA

TÉCnICA

COneCÇÃO

à web

Sim? Local

dISPOSITIVOS

eM que ACede

à web

eXPeRIÊnCIA COM

PAGAMenTOS

OnLIne

MOTIVAÇÃO

Estudante Carina Andreia Feminino 16Estudante Ensino Secundário

Estudante Português — Não Não Sim 6 9h- 12h 6 impaciente4 - Boa interacção com computadores

Casa e Escola Portátil Sim Não ficar na fila

Trabalhador Filomena Silva Feminino 45Empregada Doméstica

— Português — Não Sim Não 5 7h-8h, 17h-19h 5 impaciente

5 - Navegar na internet; ler emails; impressão de documentos.

Casa Computador Físico Não

Não ter que me deslocar a pé fora da minha linha de utilização para comprar senhas

Idoso Eusébio Ferreira Masculino 70Dirigente Desportivo

3ª idade PortuguêsProblemas Cardíacos

Não Sim Sim 4 9h-10h, 17h-19h 5 paciente

Algo limitado na interacção com os computadores (“ Não entendo lá muito disso dos computadores só sei ir à internet e pouco mais.”).

Casa e no local de trabalho.

Computador Físico Não

Não ficar na fila e não pagar tanto quando se esquece do passe ou senha

Deficiente motor Pedro Martins Masculino 45Funcionário Call Center

— PortuguêsMobilidade condicionada

Não Não Não 2 12-14h, 22h-24h 6 paciente7— Bastante experiente

Smartphone e portátil

Smartphone e portátil Sim

Comprar senhas em qualquer sítio onde eu me encontrar, não precisar de me deslocar por pontos de venda

Turista Jonh White Masculino 33Diretor Marketing

— Inglês — Não Não Sim 37h-8h, 12h-14h, 17h-19h

6 paciente9 -Aptidões avançadas

Smartphone e portátil

Smartphone e portátil Sim

Comprar senhas em qualquer sítio onde eu me encontrar, não precisar de procurar por pontos de venda


Como o bTicket é idealizado como um serviço que será utilizado por milhares de utilizadores, a amostra realizada apresenta (de forma fictícia) as entrevistas realizadas a um total de 100 pessoas. Para tal, a entrevista foi dividida em 3 fases diferentes: apresentação do entrevistado, serviço actual e serviço bTicket.De seguida apresentamos alguns resultados destas entrevistas:

ESTUDANTEnome: Mariana Gomes Ferreira Género: Feminino Idade: 22Profissão: Estudante Ensino SuperiorAufere desconto: EstudanteIdioma: PortuguêsLimitações Físicas: NenhumaPossui viatura pessoal: Sim = motoLocalização geográfica das lojas favorável: NãoLocalização geográfica das paragens favorável: Simnúmero médio de viagens por dia: 4Período do dia: 8h-12h, 17h-19hdias de viagem (0-7): 5Padrão de utilização: Carrego o passe ao fim de cada mês na Praça da Republica e apanho o autocarro na mesma zona. Demoro cerca de 25 min a fazer esta tarefa.Opinião sobre o serviço actual: simples mas pouco eficiente, existe quase sempre fila para renovar o passe no fim do mês. Não tenho um serviço alternativo para o fazer.Atitude: Por vezes vejo-me sem tempo para renovar o passe e vejo-me obrigada a comprar senha única dentro da viatura.

APRESENTAçãO DO NOVO SERVIçO BTICkETexperiências técnicas (1-10): 4 - Boa interacção com computadoresTem conexão à Internet? Se sim, onde?: Sim: em casa, na universidade e na ruaem que tipo de dispositivos tem acesso à Internet: Portátil e telemóvel.experiência com pagamentos online: SimMotivação: Não ficar na fila, poder sair mais tarde de casa e renovar o passe pelo caminho e não precisar de pagar com dinheiro nem ter de usar bilhete físico.

ENTREVISTAS AOS UTENTES6.4

UTENTE REGULARnome: Filomena Silva Martins Género: Feminino Idade: 45Profissão: Empregada DomésticaAufere desconto: NenhumIdioma: PortuguêsLimitações Físicas: NenhumaPossui viatura pessoal: NãoLocalização geográfica das paragens favorável: SimLocalização geográfica das lojas favorável: Nãonúmero médio de viagens por dia: 3Período do dia: 7h-8h, 17h-19hdias de viagem (0-7): 5Padrão de utilização: Deslocamento a um posto de venda, possível espera na fila, compra de senha, dirige-se ao autocarro, possível fila de entrada no autocarro e passar a senha.Opinião sobre o serviço actual: Os postos de venda disponíveis não vão de encontro às minhas necessidades, pois não estão perto dos meus locais de trabalhoAtitude: Não tenho mais viagens e estou a ir/vir do trabalho. Os postos de venda não se encontram em localizações favoráveis

APRESENTAçãO DO NOVO SERVIçO BTICkETexperiências técnicas (1-10): 5 - Navegar na internet; ler emails; impressão de documentos.Tem conexão à Internet? Se sim, onde?: Sim, em casaem que tipo de dispositivos tem acesso à Internet: Computador fixoexperiência com pagamentos online: NãoMotivação: Não ter que me deslocar a pé fora da minha linha de utilização para comprar senhas.


IDOSOnome: Eusébio da Silva Ferreira Género: Masculino Idade: 70Profissão: Dirigente DesportivoAufere desconto: 3ª IdadeLinguagem: PortuguêsLimitações Físicas: Problemas CardíacosPossui viatura pessoal: NãoLocalização geográfica das lojas favorável: SimLocalização geográfica das paragens favorável: Simnúmero médio de viagens por dia: 4dias de viagem: Dias úteisPadrão de utilização: Deslocamento à loja, possível espera na fila, compra de senha, dirige-se ao autocarro, possível fila de entrada no autocarro e passa o passe/senha.Opinião sobre o serviço actual: limitado, não gosta por vezes de estar à espera na fila. Quando não tem senha, demora muito tempo a pagar ao condutor e torna-se caro.Atitude: Gostava de ter um preço mais baixo quando se esquece da senha, e que o processo para tal não demorasse tanto tempo.

APRESENTAçãO DO NOVO SERVIçO BTICkETexperiências técnicas: Algo limitado na interacção com os computadores (“Não entendo lá muito disso dos computadores, só sei ir à internet e pouco mais!”).Tem conexão à Internet? Se sim, onde?: Sim, em casa e no local de trabalho.em que tipo de dispositivos tem acesso à Internet: Computador fixo.experiência com pagamentos online: Não.Motivação: Não ficar na fila e não pagar tanto quando se esquece do passe ou da senha.

TURISTAnome: John White Género: Masculino Idade: 32Profissão: Director MarketingAufere desconto: NãoLinguagem: InglêsLimitações Físicas: NãoPossui viatura pessoal: NãoLocalização geográfica das lojas favorável: NãoLocalização geográfica das paragens favorável: Simnúmero médio de viagens por dia: 3dias de viagem: equivalente aos dias de estadia (variável)Período do dia: 7h-8h, 12h-14h, 17h-19hPadrão de utilização: Desorientação típica do turista numa cidade nova: desconhecimento do funcionamento de transportes que a cidade oferece. Na melhor das hipóteses: deslocamento a um quiosque onde se vendem revistas, comprar um pack de viagens, procura do autocarro ideal para visitar os locais que pretende, dirige-se para a local de paragem do autocarro, possível espera, possível fila de entrada no autocarro e passar a senha.Opinião sobre o serviço actual: limitado, necessidade de um sistema onde possa comprar as ditas senhas onde quer que eu me encontre.Atitude: Simplificação e celeridade do processo; paciente (apesar de tudo).

APRESENTAçãO DO NOVO SERVIçO BTICkETexperiências técnicas: AvançadasTem conexão à Internet? Onde?: Sim, no Hotel e nos cafés e sitios públicos.em que tipo de dispositivos tem acesso à Internet: telemóvel e computador portátil/ tablet.experiência com pagamentos online: SimMotivação: Conhecer a cidade de forma económica comprando senhas em qualquer sítio onde eu me encontrar sem não precisar de procurar por pontos de venda.


DEFICIENTE MOTORnome: Pedro Martins Género: Masculino Idade: 45Profissão: Funcionário Call CenterAufere desconto: NãoLinguagem: PortuguêsLimitações Físicas: Mobilidade condicionada (cadeira de rodas)Possui viatura pessoal: NãoLocalização geográfica das lojas favorável: NãoLocalização geográfica das paragens favorável: Nãonúmero médio de viagens por dia: 2dias de viagem: Segunda - SábadoPadrão de utilização: Apresenta dificuldades em aceder às viaturas, como tem de entrar pela porta traseira, maior parte das vezes pede a um terceiro que lhe valide o passe junto do aparelho. Na renovação mensal, feita na loja, torna-se um transtorno porque a mesma apresenta obstáculos físicos que lhe dificultam a tarefa.Opinião sobre o serviço actual: Limitado, necessidade de um sistema onde possa comprar as ditas senhas onde quer que eu me encontre, evitando o deslocamento aos pontos de venda — parâmetro muito importante tendo em conta a minha condição físcas e as próprias dificuldades com que os deficientes motores são confrontados em plena via pública.Atitude: Celeridade e facilidade no processo de compra de senhas;

APRESENTAçãO DO NOVO SERVIçO BTICkETexperiências técnicas: AvançadasTem conexão à Internet? Se sim, onde?: Sim, telemóvel e computador portátil.em que tipo de dispositivos tem acesso à Internet: Smartphone, Portátil.experiência com pagamentos online: SimMotivação: Comprar senhas em qualquer sítio onde eu me encontrar, não precisar de me deslocar por pontos de venda;

Identificadas as nossas 5 classes de utilizadores, o passo seguinte era o de criar a persona respectiva a cada classe. Nesta página apenas apresentamos as nossas cinco personas.

PeRSONAS6.5

EstudanteA Alice Matias é uma jovem portuguesa, estudante de 18 anos, reside em Coimbra e quer viajar de autocarro. Aufere desconto de estudante, não tem qualquer limitação física, não usa viatura própria (para circular na cidade) e é utente regular da rede de transportes dos SMTUC. O desconto que aufere tem de ser revalidado todos os anos lectivos e o pagamento tem de ser efectuado numa base mensal. Por vezes fica descontente com o tempo que tem de aguardar na fila para comprar o passe e gostava de adquirir o passe de forma mais ágil e rápida.A sua motivação em usar o serviço bTicket deve-se ao facto de ser um serviço que usa as novas tecnologias, o que é um grande estímulo para as pessoas da sua faixa etária devido a estarem sempre actualizadas sobre esta matéria e de terem um gosto especial.


Utente regularO Hugo Pinheiro é um indivíduo que usa regularmente a rede de transportes dos SMTUC. Actualmente não estuda, não tem qualquer limitação física, tem actualmente 43 anos e não usa viatura própria para circular dentro da cidade. Compra uma senha de autocarro a cada duas semanas, mas quando se dirige à loja fica descontente com o tempo que demora a comprar as senhas. Gostava de o fazer mais rapidamente e não gosta de quando se esquece das senhas, ou as perde, ter que comprar uma nova junto do condutor.O objectivo do Hugo com este serviço é o de poupar tempo, pois ainda gasta algum tempo quando se desloca a um posto de venda. Isto acontece porque o posto de venda mais próximo de sua casa não se encontra relativamente perto, o que lhe causa grande transtorno, sentimento esse que deixará de existir ao usar o bTicket.

IdosoO Horácio Rodrigues é um individuo, com 65 anos, que mora em Coimbra e é utente regular dos SMTUC. Por ter tal idade recebe um desconto relativo a idosos no passe mensal do serviço de autocarros. Opta por circular de autocarro em vez usar carro próprio por questões relativas à prolongada idade ou por opção própria. Não gosta de estar tanto tempo de pé à espera na fila quando vai renovar o passe e gostava de não ter tempo de espera para o comprar.Devido à sua idade, o Horácio já se sente muito cansado para ter de se descolar a postos de venda, pelo que está bastante motivado com a hipótese de ter de deixar de fazer estas deslocações. Além disso, o facto de ter família em casa é uma mais valia para ajudá-lo a usar o serviço bTicket.


TuristaO Albert kelekolio, de 39 anos, usa exporadicamente o serviço de autocarros dos SMTUC, ou seja, não viaja nestes numa base regular. Trabalha para o ramo da restauração nas Caraíbas e viaja bastante para conhecer novas gastronomias, principalmente a chanfana. Adquire senhas de autocarro em vez de passe quando necessita de viajar.Utiliza o serviço somente quando não tem outra forma melhor para se deslocar. Ele desejaria não ter de se deslocar ao ponto de venda para adquirir senhas mais baratas para viajar.O Albert não tem grande familiarização com o actual serviço dos SMTUC, mas só a ideia de um novo serviço que faz uso das novas tecnologias já é motivação que lhe chegue quando tiver de se deslocar de autocarro.

Deficiente MotorA Rosa Mota, de 37 anos, é utente do serviço de autocarros, tem limitações motoras, e por isso é-lhe atribuído um desconto relativo aos passes (mensais). Viaja regularmente através dos autocarros dentro de Coimbra. Devido às limitações físicas, não consegue conduzir viatura própria, pelo que desejava não ter de se deslocar a um ponto de vendas para adquirir o passe para viajar nos SMTUC.Com o novo serviço, a Rosa está extremamente feliz por poder comprar viagens em casa, pois é muito difícil para ela dirigir-se a um posto de vendas devido à sua condição física. Ela espera que com este serviço as pessoas que estão na mesma situação dela tenham um melhor tratamento, pelo que tem o objectivo de usufruir e divulgar a bTicket desde o início.


Identificar o processo de estruturação do serviço apresenta-se como um parâmetro fundamental na construção da aplicação. A estrutura do projecto está fortemente relacionada com a metodologia do seu desenvolvimento. Fazer uma aplicação user centered design, implica que se identifiquem as camadas por que o projecto avança de modo a poder identificar características ou mesmo rever parâmetros anteriormente desenvolvidos. As tarefas do bTicket, inseridas dentro da interface, como visto na imagem superior, serão desenhadas consoante as necessidades dos utentes dos SMTUC, na página 32 podemos observar o primeiro esquema da estrutura da aplicação, onde estão identificadas as tarefas que o utilizador pode realizar, bem como as sub-tarefas e pré-requisitos inerentes ao processo de validação :• Registar Conta - esta tarefa é muito importante uma vez que para usufruir

do nosso serviço, no que toca a comprar viagens e a acções derivadas de tal, é necessário estar registado no nosso sistema. Esta tarefa apenas necessita de ser efectuada uma vez, aquando da primeira utilização do bTicket.

• Gerir Conta - como em quase todos os serviços, devemos dar a possibilidade aos utilizadores de gerirem a sua conta, nomeadamente, os seus dados pessoais. Por exemplo, se um utilizador alterar de número de telefone convém que o sistema lhe permita inserir o novo número para poder receber viagens no seu telemóvel.

TAREFAS7

• Comprar Viagens - a tarefa mais importante do nosso serviço. A maior parte dos utilizadores do nosso serviço o que pretendem é ter um sistema de venda/compra de senhas mais fácil e rápido de utilizar. Aquando da compra de viagens, é ainda permitido que definam mais alguns parâmetros. De relembrar que para o fazerem têm de estar registados no nosso sistema.

• Consultar Saldo - consultar o saldo é uma acção que depende da tarefa Comprar Viagens, pois apenas se poderá ter saldo, ou não, caso se tenha comprado viagens anteriormente.

• Recuperar Viagens - assim como a tarefa Comprar Saldo, também esta está directamente ligada à tarefa Comprar Viagens, pois apenas podemos recuperar viagens perdidas que tenham sido compradas anteriormente. Para recuperar viagens, o utilizador terá que inserir alguns dados, o serviço irá validá-los e, em caso de sucesso, serão devolvidas ao utilizador as senhas que tinha perdido.

• Consultar Informação do Autocarro - trata-se de uma tarefa simples, pois o nosso serviço redireccionará os utilizadores para a página dos SMTUC para obterem a informação pretendida.

• Obter Ajuda - sempre que necessário, a bTicket disponibiliza aos utilizadores três formas diferentes de resolverem possíveis problemas ou esclarer eventuais dúvidas.


Esta é a estrutura de fluxo de navegação, disposta hierarquicamente - HTA (Hierarchical Task Analysis).Esta está ainda passível de sofrer pequenas alterações, dependendo de ajustes na estrutura e posterior desenho da aplicação.

ANáLISE DE TAREFAS7.1


Na criação do cenário optámos por seleccionar 3 tarefas importantes da nossa lista de tarefas e criar um único cenário englobando estas 3 tarefas: Consultar Saldo de Viagem, Comprar Viagens e Recuperar QR Code. No cenário criado por nós, usámos como base a persona correspondente à classe Utente Regular. O cenário criado foi o seguinte:

Sr. Hugo Pinheiro é um funcionário da Câmara Municipal de Coimbra 3 e pretende efectuar uma tranquila viagem para o trabalho 1, através do autocarro 14T dos SMTUC 3, nesta manhã de Segunda-Feira 3. Para tal, entra no sistema bTicket, efectua o login usando os seus dados pessoais 7, e acede por fim à sua área pessoal. Procede à verificação do saldo das suas viagens indo ao menu de “Consultar Saldo de Conta” 2 e seleccionando o QR Code activo 2. Verifica que não dispõe, de momento, de viagens para usufruir, pelo que segue ao menu de “Comprar Viagens” para efectuar a compra das viagens 2 de que tanto necessita de modo a chegar ao trabalho a tempo. No menu, onde tem as hipóteses Comprar Viagens e Comprar Passe, selecciona Comprar Viagens 2 e escolhe a quantidade que pretende comprar 2 e como quer obter o respectivo QR Code 2, sendo que neste caso escolhe receber no seu smartphone. O passo seguinte é efectuar o pagamento 2, onde verifica o resumo e o custo total da compra e insere os seus dados de cartão de débito/crédito 7. Tendo todos os dados preenchidos, o sistema valida a informação e, caso esteja tudo correcto, processa a compra e envia o QR Code para o Sr. Hugo. Satisfeito 5 com a rapidez e simplicidade com que obteve as viagens, pega nos seus haveres e segue em direcção à paragem de autocarro 3. O 14T chega no horário previsto e o Sr. Hugo embarca validando o seu QR Code com sucesso.Durante o almoço o Sr. Hugo recebe uma chamada urgente do seu filho 3, forçando-o a atender preocupadamente 6. Após a conversa, pousa o telemóvel no tabuleiro de modo a estar acessível para a segunda chamada do seu filho com novidades. No entanto, com a agitação na cantina, uma senhora, sem qualquer culpa, deixa cair o copo com água por cima do tabuleiro estragando o telemóvel 6. Irritado 5 por ter ficado sem telemóvel para tratar do assunto urgente, decide então ir para casa para apoiar o filho 6, mas tem o problema de ter ficado sem o seu modo de validação de QR Code 4, pois continha-o no telemóvel 6. Apressou-se a ir ao seu posto de trabalho, acedeu ao sistema bTicket, efectuou o login com os seus dados 7 e na área pessoal procede a “Recuperação de QR Code” 2. Selecciona o QR Code mais recente e visualiza se contém as viagens disponíveis 2 e confirma que é o correspondente à compra que efectuou nessa manhã. Escolhe esse QR Code 2 e selecciona o modo de impressão 7 uma vez que o

CENáRIO7.2

seu smartphone está estragado 4. O QR Code é impresso, o Sr. Hugo apressa-se a ir para a paragem, apanha o autocarro e, aliviado e satisfeito 5 pela rapidez com que resolveu o imprevisto e encontra-se a caminho de casa, chega a casa e assiste o seu filho com o problema com que se encontrava.

1 - Objectivo (Goal)2 - Tarefa (Task)3 - Contexto (Context)4 - Erro (Error)5 - Emoção (Emotion)6 - Problema (Drama)7 - Requisitos (Requirements)


Na análise de requisitos efectuada sobre o nosso serviço foram listados diversos requisitos, como por exemplo, comprar viagem, autenticação e ver horários.De seguida detalhamos dois dos requisitos mais importantes.

REQUISITOS7.3

Requisito 3 Nome Comprar Viagem tipo Funcional

DescRição O serviço tem que fornecer uma interface que permita aos utilizadores comprar viagens, sendo que podem ainda definir o tipo de viagens, quantidade e modo de entrega.DaDos Dados da transacção, de utilizadores e preçárioambieNteFísico —Deve permitir a compra sem qualquer restrição sonora;Tecnológico —Necessita de ligação à Internet;Social— Não permitir às pessoas próximas ao utilizador visualizarem informação confidencial;Organizacional — Permitir reportar anormalidades do serviço;caRacteRísticas Pedido de confirmação de transacção

Requisito 8 Nome Recuperar Viagem Viagem tipo Funcional

DescRição O serviço deve permitir ao utilizador recuperar o QR Code activo pela forma que desejar.DaDos Dados do utilizador e QR Code pessoaisambieNteFísico: Deve permitir a compra sem qualquer restrição sonora;Tecnológico: Necessita de ligação à Internet;Social: Só é possível recuperar QR Codes do indivíduo que efectua a recuperação;Organizacional: Permitir reportar anormalidades do serviço;caRacteRísticas Permitir a repetição da recuperação


Neste capítulo é nos pedido que analisemos o serviço como sendo um sistema, através do modelo kami & kaner, e ainda que o detalhemos recorrendo às técnicas de Service Blueprinting.

Usando o modelo mencionado anteriormente, especificámos os diversos elementos, que a este pertencem, com base no nosso serviço.

ClientesOs clientes que utilizarão o nosso serviço foram caracterizados e identificados num dos capítulos anteriores, Análise do Utilizador, sendo que temos 5 classes de utilizadores: estudantes, utentes regulares, idosos, turistas e deficientes motores.

ObjectivosOs objectivos do nosso serviço têm vindo a ser apresentados ao longo dos capítulos anteriores. No último capítulo, Análise de Tarefas, é onde damos maior ênfase a este tema uma vez que apresentamos as diferentes tarefas que o utilizador pode realizar no nosso serviço. A lista de tarefas que enumerámos é a seguinte: comprar viagens, consultar saldo de viagem, consultar horário e itenerário e recuperar QR Code.

InputsNo nosso serviço existem vários tipos de input, sejam eles a nível físico ou pessoal, sejam a nível de informação e/ou a nível de conhecimento. Nestas entradas do sistema existem, por vezes, algumas restrições (limitações) de cariz financeiro (utentes com vencimentos baixos) ou físico (utentes com deficiências físicas ou outro tipo de limitações).Fisicamente um cidadão (pode ou não já ser utente dos SMTUC) tem de passar um QR Code por um leitor de forma a gerar um input inicial para o sistema.A nível de entrada de informação no nosso sistema um utilizador pode: reportar anomalias descrevendo uma anomalia, introduzir/alterar os dados da conta (aquando do registo ou da alteração de dados de pagamento) e introduzir/alterar dados pessoais.

ANáLISE DO SERVIÇO8Uma pessoa, a nível de conhecimento, tem obrigatoriamente de saber como interagir com material informático (computadores, smartphones e/ou tablets) de forma a se registar e, posteriormente, utilizar o serviço. Tem também de saber, abstractamente, como funcionam os QR Codes.O(s) pagamento(s) efectuado(s) para usufruir do serviço são feitos através da web (PayPal). Para utilizarem o serviço, os clientes têm apenas de possuir um dispositivo com ligação à Internet.

OutputsA utilização do serviço bTicket origina, dependendo da tarefa, outputs específicos de diversos tipos. Em termos físicos, o cliente, ao comprar viagens, recebe um QR Code e o respectivo recibo da compra. Depois de o QR Code ser fornecido, pelo sistema, passa a ser pemitido a um cidadão viajar nos autocarros dos SMTUC, tornando-se assim num utente SMTUC, caso não o seja.O serviço “produz” vários tipos de informação necessária que contribui para o bom funcionamento do sistema. Assim sendo, é necessário, por exemplo, fornecer informação de confirmação/rejeição da validação de um QR Code e informação de confirmação/negação relativos ao pagamento.Durante a prestação do serviço irá haver gastos, montantes tabelados, nomeadamente, quando se geram QR Codes e quando se compram viagens. Estes pagamentos, por parte dos clientes, geram receitas para os SMTUC.

ProcessosO serviço bTicket procura ter o máximo de disponibilidade possível por ano, fazendo com que os utilizadores possam usufruir do serviço a qualquer hora, a qualquer dia da semana. Serão elaborados processos de recolha de opiniões por parte dos utentes sobre o serviço via pessoal e/ou electrónica.É um serviço que não requer registro obrigatório e lida com pagamentos via Internet, por parte dos utilizadores, aquando da compra de viagens.Uma vez que será um serviço utilizado pelos SMTUC, eles estarão encarregues de todos os processos que envolvem a promoção do serviço e atendimento a clientes, desde o serviço de call center, ajuda a nível de utilização ao apoio nos postos dos SMTUC. Os problemas de nível mais técnico serão reportados pelos funcionários dos SMTUC à equipa bTicket e a resolução será efectuada.Existem várias restrições relativas a este serviço uma vez que só será possível ter um registo por email, e não é possível que sejam validados dois QR Codes em simultâneo no mesmo leitor.

SERVIçO COMO UM SISTEMA8.1


Em termos de monotorização e avaliação da performance, serão efectuados períodos de recolha de métricas relativas à velocidade de resposta do sistema, velocidade e integridade das transacções dos pagamentos, e o ganho, tempo de espera na compra de bilhete e tempo de entrada e validação da viagem no autocarro.

Human EnablerA equipa em que se inserem os provedores do “core” do serviço consiste em três Engenheiros Informáticos e dois Designers (equipa bTicket).Os prestadores de serviços de pagamento são prestadores de suporte dentro do serviço bTicket. Sem estes não seria possível aos utilizadores pagarem para obter passes/senhas de viagens.Para o bom funcionamento deste serviço tem de haver uma gestão, assente num estilo democrático, ao nível contabilístico, de tesouraria, dos recursos e dispositivos tecnológicos por parte das entidades responsáveis pelo funcionamento do serviço.Prevê-se que o serviço bTicket venha a fazer parte da propriedade dos SMTUC e, visto que este é um serviço municipalizado, podemos considerar o serviço como uma propriedade municipal.Existem dispositivos que tornam mais fácil este fornecimento de tarefas por parte dos provedores, consistindo estes única e exclusivamente em dispositivos com ligação à Web.

Physical EnablerA entidade responsável pela prestação de serviço são os SMTUC, pois esta entidade pertence ao município.As estruturas físicas que “albergam” servidores (e outro material informático) e/ou pessoas relacionadas com o funcionamento do sistema são: a sede dos SMTUC, os pontos de venda e de informação dos SMTUC e a Câmara Municipal de Coimbra.Os equipamentos necessários para o funcionamento do serviço consistem em: leitores de QR Code que se encontram no interior de cada autocarro, o servidor onde vai estar alojado o servidor Web, dispositivos com ligação à Internet que os utilizadores usam para comprar passes/senhas e para mostrar o QR Code, aquando da sua validação, e impressoras, caso o utilizador não tenha um dispositivo móvel.Todos os utentes, edifícios e equipamentos estão geograficamente na área metropolitana de Coimbra.

Informatic EnablerA nível informativo têm de existir forma de dar a conhecer aos utentes o funcionamento do serviço, quer seja ao nível do Website, quer seja relativo ao uso dos QR Codes aquando da validação da viagem.

Esta informação vai estar disponível na forma de panfletos e cartazes publicitários para dar a conhecer aos utilizadores a existência deste serviço.Posteriormente, os utilizadores vão ter que adquirir este conhecimento relativamente a alguns processos, mais especificamente: usar QR Code, fazer registo no sistema online, efectuar pagamentos online e recuperar QR Code.A informação que os clientes necessitam de adquirir para interagirem correctamente com o sistema está explicita em cartazes informativos dentro do autocarro, perto do leitor de QR Code e através de vídeos demonstrativos de como efectuar o registo, efectuar pagamentos e comprar viagens.Estará também disponível online toda a informação relativa às políticas de privacidade e segurança.

AmbienteEm termos de caracterização do ambiente em que o serviço bTicket está envolvido, é possível, através dos requisitos do serviço, poder compreender quais as suas necessidades e o que está ao dispor, nomeadamente, factores físicos, monetários, tecnológicos, entre outros. É um serviço orientado a todas as classes sociais, existentes num meio urbano comum, onde qualquer pessoa poderá utilizar os autocarros exporadicamente ou regularmente.Tendo em conta os dois requisitos anteriormente apresentados, é possível destacar as necessidades tecnológicas e físicas a respeito do sistema de compra e recuperação de viagens,, bem como as restrições de conhecimento base necessário por parte de cada utente para o sucesso da utilização do serviço.É um ambiente onde não existe concorrência uma vez que só existe um serviço de transportes públicos na cidade de Coimbra (SMTUC) e utilizaria o serviço bTicket, não chegando a ter duas máquinas de validação de dois serviços de bilhetes distintos em cada autocarro.O serviço bTicket necessita de dois tipos de fornecedores, fornecedores das máquinas de leitura de QR Code e fornecedores do serviço de pagamento via Internet (por exemplo, PayPal, MasterCard).


Recorrendo a esta técnica, introduzida por Shostack, detalhámos todas as acções e interacções dos utilizadores com o serviço. O resultado final obtido foi:

SeRvICe BluePRINTING8.2


O presente capítulo serve como uma introdução ao desenvolvimento do layout do nosso serviço, podendo dividir-se em quatro fases. Numa primeira fase extendemos o nosso cenário de modo a incorporar mais alguns elementos, como interação, preço, participantes, etc. De seguida elaborámos uma storyboard relacionada com este cenário, sendo que agrupámos estas duas primeiras fases, uma vez que se completam, e de modo a ser mais perceptível. Na terceira fase foram desenhados os sketches da storyboard que ilustram as várias interações entre a personagem do cenário e o serviço bTicket. Por fim, foi implementado cerca de 70% do layout final da aplicação para começarmos a estudar quais as melhores interações entre os utilizadores e o bTicket.

Sr. Hugo Pinheiro k é um funcionário da Câmara Municipal de Coimbra c e pretende efectuar uma tranquila viagem para o trabalho a, através do autocarro 14T dos SMTUC c, nesta manhã de Segunda-Feira, 2 de Abril.

PROTÓTIPO DO SERVIÇO9Notas a ter em consideração ao analisar a Blueprinting:

1- Todas as actividades que os utilizadores podem fazer estão representadas no esquema;2- Não seria viável standardizar os processos uma vez que o proposito desta Blueprint é o de conseguir detalhar as acções e interacções dos utilizadores com o nosso serviço, de modo a que uma pessoa sem conhecimentos prévios das áreas de 3- Gestão e Informática consiga interpretar na totalidade o serviço bTicket;Existe uma solução na Blueprint que resolve a perda de QR Codes por parte dos utilizadores, permitindo-lhes efectuar a recuperação do mesmo caso este esteja registado. Esta solução pode ser vista na Blueprint na secção Acções dos Clientes;4- É possível destacar aspectos importantes a monitorizar no nosso serviço através do esquema anterior, sendo estes, tempos de resposta, quer seja da validação de uma viagem, quer seja da confirmação de pagamento, bem como monitorizar os fluxos de acesso ao nosso serviço, ou seja, saber em que alturas do dia/semana/mês há mais ou menos utilizadores;5- A análise do nosso serviço foi toda ela centrada no cliente desde o início, pelo que de momento não existe nenhuma alteração que possa contribuir para um serviço mais centrado no cliente.

CENáRIO ExPANDIDO & STORyBOARd9.1


Para tal, através do seu computador, acede im à página online li do serviço bTicket, efectua o login usando os seus i dados pessoais gi, e acede por fim à sua área pessoal. Procede à verificação do saldo das suas viagens indo ao menu i de “Consultar Saldo de Conta” e seleccionando o QR Code activo bi. Verifica que não dispõe, de momento, de viagens para usufruir, pelo que segue ao menu de “Comprar Viagens” para efectuar i a compra das viagens bi de que tanto necessita de modo a chegar ao trabalho a tempo. i

No menu, onde tem as hipóteses Comprar Viagens e Comprar Passe i, selecciona Comprar Viagens bi, insere a i quantidade de viagens que pretende comprar bi, neste caso 6 a um i preço de 3,80€, ji com IVA taxa legal em vigor h, e como quer obter o respectivo QR Code ci, sendo que neste caso escolhe receber no seu smartphone. O passo seguinte é i efectuar o pagamento ci, onde verifica o resumo e i o custo total da compra ji, e insere os seus i dados de cartão de débito/crédito. gi


Tendo todos os dados preenchidos, o sistema valida a informação e, caso esteja tudo correcto, processa a compra e envia por MMS o QR Code para o smartphone do Sr. Hugo k. Satisfeito e com a rapidez e simplicidade com que obteve as viagens, pega nos seus haveres e segue em direcção à paragem de autocarro c.

O 14T chega no horário previsto e o Sr. Hugo k embarca.


Contudo, ao validar a viagem através do seu QR Code, o leitor informa que acabou de utilizar a última viagem, o que obriga o Sr. Hugo, ao chegar ao trabalho e através do seu computador, a aceder mi à página do bTicket li e, após login, reportar o erro preenchendo devidamente o formulário, que será analisado pelos i membros da equipa de desenvolvimento bTicket ki. Não há motivo de alarme, pois i neste tipo de anomalias são reembolsadas as viagens em falta hi.

Durante o almoço o Sr. Hugo k recebe uma chamada urgente do seu filho c, forçando-o a atender preocupadamente. Após a conversa, pousa o telemóvel no tabuleiro de modo a estar acessível para a segunda chamada do seu filho com novidades. No entanto, com a agitação na cantina, uma senhora, sem qualquer culpa, deixa cair o copo com água por cima do tabuleiro estragando o telemóvel. f


a - Objectivo (Goal)b - Tarefa (Task)c - Contexto (Context)d - Erro (Error)e - Emoção (Emotion)f - Problema (Drama)g - Requisitos (Requirements)

Irritado k por ter ficado sem telemóvel para tratar do assunto urgente, decide então ir para casa para apoiar o filho f, mas tem o problema de ter ficado sem o seu modo de validação de QR Code d, pois continha-o no telemóvel f. Apressou-se a ir ao seu posto de trabalho, acedeu im novamente à i página bTicket il, efectuou o login com os i seus dados ig e na área pessoal procede a i “Recuperação de QR Code” ib. Selecciona o QR Code mais recente e i visualiza se contém as viagens disponíveis ib e confirma que é o correspondente à compra que efectuou nessa manhã i. Escolhe esse QR Code ib e selecciona o i modo de impressão ig uma vez que o seu i smartphone está estragado id.

O QR Code é impresso, o Sr. Hugo ik apressa-se a ir para a paragem, apanha o autocarro e, ao validar o QR Code, verifica que a i quantidade de viagens disponíveis já se encontra correcta il. Aliviado e satisfeito e pela rapidez com que resolveu o imprevisto e se encontra a caminho de casa, chega a casa e assiste o seu filho com o problema com que se encontrava.

h - Aspectos Legais (Legal)i - Interação (Interaction)j - Preço (Pricing)k - Participantes (Participants)L - Nível do Serviço (Service Level)M - Aspectos técnicos (Tecnical)


qR coDe

logótipo

Nº ViageNs DispoNíVeis

DaDos pessoaisDo utilizaDoR

históRico De ViageNs

SkeTCHeS9.2

Tendo como ponto de partida as ilustrações presentes no nosso Storyboard prosseguimos para uma análise mais exacta e organizada dos nossos elementos tendo sempre em atenção a diversidade das plataformas visuais usadas que vai desde computador portátil ou fixo, aos telemóveis ou smartphones, tablets e até à plataforma de validação dos bilhetes instalada nos autocarros.

HoMEpagE (para utIlIzaDorEs rEgIstaDos)


qR coDecoRRespoNDeNte

à compRa

logótipo

Nº ViageNs a compRaR

Detalhes

efectuaR pagameNto

caNcelaR

qR coDeusaDo

Detalhes Da(s) Viagem(s)(já usaDa)

qR coDeusaDo

Detalhes Da(s) Viagem(s)

(já usaDa)

bIlHEtEs > coMprar bIlHEtE


logótipo


bilhetes hoRáRio iNfo

3

smartphone >> HoMEpagE (para rEgIstaDos)


logótipo


iNfoRmações úteis coNtactos

ViageNs DispoNíVeis

iNfo

PLATAFORMA AUTOCARRO >> valIDação bIlHEtE


qR coDe

logótipo

botão —impRimiR blhete

Detalhes Do bilhete

iD acção: RecupeRaR bilhete

bIlHEtEs > rEcupErar bIlHEtE


Como referido anteriormente, no texto introdutório ao capítulo 9, nesta secção apresentaremos algumas partes do layout do nosso serviço, sendo que apenas ilustraremos algumas páginas, nomeadamente, as páginas correspondentes ao processo de compra de viagens.

HIGHT FIdelITy PROTOTyPe9.3

págIna InIcIal

coMprar bIlHEtEtEs > sElEcIonar quantIDaDEs


coMprar bIlHEtEtEs > IntroDução DE EMaIl coMprar bIlHEtEtEs > EfEctuar pagaMEnto


Este capítulo consiste numa descrição resumida da fase de implementação do serviço. Inicialmente será explicada qual a framework MVC escolhida e como esta funciona. Após esta abordagem mais técnica, seguem-se as principais tarefas associadas ao desenvolvimento da página web e, por fim, as opções de design onde são destacados e justificados alguns pormenores, tanto gráficos como técnicos, da página web em desenvolvimento.

IMPLEMENTAçãO DO SERVIçO10

FRAMeWORk MvC

Em Django, os “controllers” são denominados “views”, as “views” são denominadas de “templates”, e os “models” mantêem o seu nome.As “views” são o componente que devolve e manipula os dados, enquanto os “templates” são os componentes que apresentam os dados ao utilizador. Por esta razão, o Django, por vezes, é conhecido pela framework MTV (Model, Template e View). Contudo, esta terminologia não muda o facto do Django ser uma framework MVC nem afecta o modo de como as aplicações são desenvolvidas.

Django 1.1

os MEus bIlHEtEs (após coMpra)

10.1


TAREFAS — PáGINA WeB10.2

Desenhar a estrutura para o site do serviço bTicket comprometeu um exaustivo estudo de possibilidades, onde foram avaliadas as necessidades do serviço e as condicionantes que este comprometia.

Um dos avanços mais significativos em relação aos estudos preliminares esteve relacionado com a objetividade do serviço no compromisso de apresentar uma estrutura clara e facilmente perceptível. Era necessário conseguir que o utilizador reconhecesse nos primeiros instantes em que visita o site, tanto o serviço que este oferece como o seu modus operandis.

Para tal, foi necessário recorrer a estimulos directos, ao trabalhar com uma linguagem o mais universal possível, de forma a que o utilizador reconheça, por comparação, as tarefas que lhe são permitidas.

MeNOS é MAIS

Ao implementar o site, trabalhando com as maquetas de layout desenvolvidas, levantaram-se dois problemas que não foram inteiramente antevistos, ambos relacionados com o processo de desenhar primeiro o conteúdo de forma estática. O fluxo de informação apresenta-se ainda demasiado denso, não havendo um processo sequêncial que diminua significativamente a informação apresentada ao utilizador.

Seguidamente, a falha prendia-se com a disposição dos elementos. Desenhar uma plataforma em HTML5 e CSS3, permite que o conteúdo seja dinâmico e responda em tempo real ao tamanho da janela do browser, adaptando-se em ordem, tamanho ou mesmo género de conteúdo. Era um objectivo fundamental garantir o serviço em qualquer genero de terminal, independentemente das dimensões do ecrã. O Responsive Web design1, uma recente nomenclatura que nasceu juntamente com o HTML5, define exactamente esta nova realidade. Mas a nova abordagem aos layouts para a web traz consigo uma metodologia de desenvolvimento também bastante diferente. Desenhar o layout deixa de ser um processo estático, nomeadamente no site www.log.pt, onde encontramos um artigo bem explícito que expressa esta nova realidade. Das nove dicas para os recentes criadores de conteúdos responsive web, destaca-se a 6ª:

1 O termo Responsive Design é a forma de, utilizando grelhas fluídas, layouts fluídos e as @media queries (http://reference.sitepoint.com/css/mediaqueries), conseguir adaptar o site ao manancial de dispositivos com diferentes tamanhos de ecrã que existem hoje.

“Não utilizar o Photoshop/Fireworks. Devemos desenhar os nossos componentes no browser. É praticamente impossível desenhar um layout fluído no Photoshop. Começar no browser desde o primeiro instante é uma muito boa prática.2”

Esta é sem duvida a razão porque a versão final e funcional da plataforma se distância tanto dos estudos anteriores. Constuiu-se o site a partir do código, dentro do browser, tendo como objectivo a apresentação de informação de forma sequêncial, e garantindo sempre o destaque às tarefas prioritárias: comprar bilhetes, consultar e usar bilhetes.

2 http://log.pt/blog/2011/11/9-dicas-sobre-responsive-web-design/


OPçõES DE DESIGN — PáGINA WeB

Passemos, de forma breve, a realçar alguns pontos fundamentais do serviço e a explicar as opções tomadas:

MeNuO menu é a primeira área apresentada, como na maioria dos serviços web, acede-se por ele à maioria das tarefas de primeiro nível. O próprio logótipo do serviço assume a dupla função de branding e de link de acesso à página inicial do serviço. Sendo o serviço uma bilheteira on-line de transportes urbanos, é aqui que se encontram as principais tarefas do serviço.

Ainda no menu encontramos, como uma hierarquia secundária, os acessos à Help Assistance e aos serviços externos, como por exemplo, todos os links que estão directamente associados ao serviço dos SMTUC.

Ultimamente, numa secção diferenciada, encontra-se a área de utilizador, onde se acede a todos os parâmetros para registar uma nova conta ou fazer login.

Importa salientar que, quando as dimensões do ecrã são bastante reduzidas, o menu colapsa ficando apenas para acesso directo à pagina inicial e a área de utilizador.

BANNeRO banner é, à partida, uma ferramenta secundária, mas entende-se que, na fase de lançamento e promoção do serviço, este se torne um recurso importante na promoção e esclarecimento do serviço, daí o seu destaque no topo da página, onde estão apresentadas mensagens de auto-promoção e esclarecimento.

CORPO dO SITeDesde cedo houve a clara noção de que a pagina inicial devia dirigir o utilizador a apenas dois grandes objectivos: destacar a aquisição de bilhetes e a consulta dos adquiridos. Por esta razão, o corpo do site arranca com os seus menus fechados, induzindo o utilizador a explorar e assimilar estas duas áreas distintas.

A opção por conteúdo em gavetas soluciona esse problema e mantém constantemente o layout da página simples, focando o objectivo do utilizador: quando este acede à gaveta “Buy Tickets”, a segunda gaveta “Consult my tickets” é automaticamente fechada, e vice versa.

10.3


COMPRAR BILheTeSA tarefa principal do serviço subdivide-se em duas partes distintas: a compra de bilhetes normais e a aquisição de passe. Importou não desenhar inteiramente o serviço, mas fazer de forma consciente esta hierarquisação e extratificação de tarefas de modo a manter durante todo o proceço a informação clara.

No campo de compra de bilhetes, as opções de compra são dispostas numa única select list, onde ainda é incluído, tanto a quantidade de viagens como o preço que lhe está associado. Após esta selecção, é apresentado o campo de email para os utilizadores não registados. Desta forma, o formulário de preenchimento fica tão curto quanto possível e o utilizador pode prosseguir para o pagamento em segundos.

“whAT yOu See IS whAT yOu geT”Apesar de ser um formulário bastante curto e objectivo, onde se vê claramente a opção de compra escolhida, é necessário devolver ao utilizador uma resposta por parte do serviço, sendo esse feedback assegurado de duas formas distintas. A principal é dada pelo resumo de compra, onde são apresentado os dados referentes à presente aquisição, sendo que estes campos estão ainda diferenciados por um estado, como por exemplo no caso do campo cliente, onde este campo apresenta novamente o username, caso haja um registo, ou destaca com um label amarelo, caso não exista, isto porque é aconselhado que a compra seja efectuada neste modo. Este resumo repete-se na área de destaque onde se efectua o pagamento. À partida, é uma opção que por redundância de informação o processo de design devia abolir, mas tem uma segunda tarefa não menos importante neste campo distinto, não apenas o feedback por parte do sistema, mas para relembrar o utilizador na altura em que faz o pagamento, transmitindo-lhe confiança sobre o que vai adquirir efectivamente.

AJudA de PROgReSSO eM TeMPO ReALComo o serviço bTicket era consideravelmente pequeno e simples, pretendia-se que caso o utilizador necessitasse de ajuda, esta deveria constar no Help Assistance devidamente documentada, mas, principalmente, importava que o utilizador se sentisse ajudado durante o processo. Deste modo, existem nos campos de escolha e preenchimento balões com informação de ajuda para manter a confiança do utilizador presente.


PReeNChIMeNTO de dAdOS PARA PAgAMeNTOA área de pagamento, embora hipotética, foi pensada de forma a não criar constrangimentos ou incertezas ao utilizador. Deste modo, são apresentadas as opções de pagamento on-line e recolhidos os respectivos dados do cartão.

ALeRTAS e MeNSAgeNS de PROCeSSOEste foi um recurso largamente utilizado, não de forma a tornar o serviço intrusivo, mas para que exista o necessário apoio e esclarecimento durante a sua utilização de forma a manter elevado o nível de confiança do utilizador.Mensagens de sucesso e de alerta acompanham os processos de gestão do serviço, e parte destes podem ser descartados assim que a informação se mostrar desnecessária para o utilizador.

uSO de TABSEsta opção torna a nossa navegação mais intuítiva, pois a informação fica mais organizada e de fácil acesso.

Neste caso, temos duas opções á nossa escolha, sendo que a mais usada é a aba que aparece aberta por defeito.


OS MeuS BILheTeSNesta área temos quatro tarefas distintas sendo que o facto de o utilizador estar registado faz toda a diferença.

Para utilizadores não registados e sem bilhetes para consultar apenas está disponível uma funcionalidade: “Recovery Tickets”, que mediante um código reenvia o bilhete para o email.

Assim que o utilizador não registado efectua uma compra, passa a ter disponível o bilhete comprado e a funcionalidade de o recuperar.

Para os utilizadores registados, a prioridade é ver os bilhetes disponíveis e aceder directamente ao QR Code. Importante também será consultar o seu próprio histórico (acedendo a data e hora de compra, data e hora de uso da viagem e respectivo autocarro).

skEtcHEsNa secção “Help” optámos pelo uso de sketches ilustrativos de eventuais problemas que possam surgir, facilitando assim o processo de identificação do problema por parte do utilizador.


Terminada a fase de implementação do serviço, foi altura de passarmos à sua avaliação. Esta avaliação foi feita seguindo duas abordagens: avaliar o sistema através de um questionário e fazer uma avaliação heurística.

AVALIAÇÃO DA INTERFACE11

Cátia Costa

João Nabais

Luís Veiga

Pedro Macedo

Pedro Vaz média

Desvio Padrão

1. My service describes the customer authentication process

1 1 1 1 2 1.2 0.447

2. My service describes its business model

6 7 7 7 6 6.6 0.548

3. My service does not have configuration options

7 6 6 7 6 6.4 0.548

4. My user interface provides a clear description of the service

7 7 7 7 6 6.8 0. 447

5. My service does not have a FAQ (Frequently Asked Questions) section

1 1 1 1 1 1 0

6. My service does not have a service rating based on past customer experiences

1 1 1 1 1 1 0

7. My service describes its goal, advantages, and limitations

5 7 6 6 6 6 0.707

8. My service provides a Help section 7 7 7 7 7 7 0

SelF-SeRvICe INTROSPeCTION SuRvey (SSIS)

O questionário, ao qual respondemos para avaliar o nosso serviço, foi construído juntamente com os elementos dos restantes grupos e o docente da cadeira. Após algum trabalho, o questionário final obtido é apresentado de seguida, sendo que indicamos as respostas dadas por cada um dos elementos do grupo, bem como a média e o desvio padrão.

11.1


Cátia Costa

João Nabais

Luís Veiga

Pedro Macedo

Pedro Vaz média

Desvio Padrão

9. My service does not have a description of its usage

2 2 1 1 1 1.4 0.548

10. My service describes the legal aspects that apply to the service

5 5 5 6 5 5.2 0.447

11. Service usage and marketing material

5 5 6 7 5 5.6 0.894

12. My service does not show the relationships it has with other existing services

2 2 1 2 1 1.6 0.548

13. My service does not show service provider contact information

1 3 2 1 2 1.8 0.837

14. My service does not show pricing and payment information

1 1 1 1 1 1 0

15. My service offers secure transactions

7 7 7 7 7 7 0

16. My service provides information on the current state of service provisioning

7 5 6 7 5 6 1

17. My service does not provide information on remaining states of service provisioning

2 1 2 1 1 1.4 0. 548

18. My service does not offer Customer Service

1 1 1 1 1 1 0

19. My service does not have an availability schedule

7 7 7 7 6 6.8 0.447

20. My service provides real-time accurate information

7 7 7 7 6 6.8 0.447

21. My service describes the service level (Sl) provided to customers

4 4 4 5 4 4.2 0.447

22. My service does not describe how it can be accessed using software-based mechanisms

7 7 7 7 7 7 0

Cátia Costa

João Nabais

Luís Veiga

Pedro Macedo

Pedro Vaz média

Desvio Padrão

23. My service provide a business process model which describes ‘how’ is works

7 7 7 7 6 6.8 0.447

24. My service does not describe the class of customers is targets

1 1 1 1 1 1 0

25. My service describes the type of partnerships established with other service providers

7 7 7 7 7 7 0

26. My service describes the type of problems is solve

7 7 7 7 6 6.8 0.447

27. My service does not describe the certifications it has received

3 4 5 4 5 4.2 0.837

28. My service indicates which other services it can be used with

7 7 7 7 7 7 0

29. My service does not includes documentation

1 1 1 1 1 1 0

30. My service does not indicates which technical protocols can be used to invoke the service

7 7 7 7 7 7 0

Como se pode ver pelas respostas dadas pelos alunos, e pelos resultados da média e do desvio padrão, os elementos do grupo estão bem familiarizados com o serviço, seu sistema, e respetivas funcionalidades, pelo que a veracidade das nossas respos-tas sobre o nosso serviço tem uma base sólida e mostram que os utilizadores podem confiar na administração.


AVALIAçãO HEURíSTICA11.2

Antes de mais, mencionar que a avaliação heurística efetuada foi baseada nos 10 Princípios de Nielsen. Dentro dos 5 elementos, 3 fizeram a sua própria avaliação heurística, sendo que no fim se juntaram as três avaliações para ser apresentada uma única avaliação bastante completa.

1 – VISIBILITy Of SySTeM STATuS (Visibilidade de Estado do Sistema)

O sistema é um sistema de resposta rápida uma vez que é um projeto académico e não temos um servidor muito carregado, pelo que não há necessidade de ter barras de progresso aquando das operações, porém, é explícito em cada ação o que essa ação implica em termos operacionais. Contudo, o sistema informa o utilizador se as suas ações estão a ter sucesso ou não, sendo que, quando existe um erro, este é comunicado ao utilizador, como por exemplo, preencher mal os campos de registo de conta ou os campos de compra de bilhetes. Por fim, são também apresentadas chamadas de atenção, como por exemplo, quando estamos a tratar dos pagamentos e submissão de dados, onde temos a seguinte mensagem: “Attention! ensure that all data entered is correct, if so, conclude the operation.”.

Por fim, como o modo de visualização da nossa aplicação é único, não faz sentido termos opções de configuração do modo de visualização.

2 – MATCh BeTweeN SySTeM ANd The ReAL wORLd (Transposição entre o Sistema e o Mundo Real)

O sistema foi todo pensado e desenvolvido para seguir os Web Sites mais comuns e utilizados pelos utilizadores da Internet, sendo que a interface desenvolvida é clara e coerente, o que faz com que seja mais percetível ao utilizador perceber a “linguagem do sistema” e não ter dificuldades na utilização do nosso serviço.

A primeira decisão que tomámos foi a de escolher o idioma, sendo que o escolhido foi a língua Inglesa devido a ser a língua universal. Talvez numa fase inicial, este idioma para o nosso sistema seja um entrave para os que não dominem a língua mas,

além de estarmos a falar de uma língua universal, o vocabulário usado é simples e reduzido para que as pessoas facilmente aprendam.

Dentro das 5 personas que definimos, temos consciência que os Idosos poderão ter dificuldade em usufruir do nosso serviço devido a ser necessário utilizar as novas tecnologias, pelo que estes, caso queiram usar este serviço, muito provavelmente pedirão ajuda a pessoas próximas. Ou seja, este cenário não vai bem ao encontro do mundo real, onde este tipo de personas consegue, por si próprio, deslocar-se a um posto de venda e comprar os seus próprios bilhetes.

Outra relação entre o sistema e o mundo real é a da escolha de cores para determinadas situações, nomeadamente, preenchimento de campos, botões e visualização de viagens disponíveis. Para preenchimento de campos, temos mensagens a verde, em caso de sucesso, e a vermelho, para quando os campos não foram preenchidos ou foram preenchidos incorretamente. Quanto a botões, usamos cores alusivas e muito diferentes para submissões/confirmações e para cancelamentos. Apesar de não usarmos a cor vermelha nos botões de cancelamento, usamos a cor azul para botões de confirmação. Por fim, na visualização de viagens, usamos as propriedades de cores para diferenciar senhas que tenham muitas viagens (verde) de senhas que tenham poucas (amarelo) ou mesmo nenhumas (vermelho) viagens.

Quanto ao método de pagamento, tivemos bastante atenção para que esta ação fosse de encontro aos métodos de pagamento comuns na Internet, como MasterCard e VISA, pelo que, para quem está habituado a fazer compras na Internet, esta ação é completamente familiar.

Por fim, no mundo real, as pessoas que quiserem comprar bilhetes têm a restrição de ter de se dirigir a um posto de venda específico, sendo que a restrição do nosso serviço encontra-se na necessidade de ter que se ter acesso à Internet para se comprar bilhetes.

3 – uSeR CONTROL ANd fReedOM (Liberdade e Controlo por parte do Utilizador)

Nesta área podemos dizer que o utilizador tem bastante liberdade e controlo, quer a nível de gestão de conta quer a nível de compra de bilhetes.


A qualquer instante, o utilizador pode aceder ao serviço e editar os seus dados, sendo que tem a opção de cancelar esta edição se por ventura mudar de ideias durante o processo de edição. Quanto à compra de bilhetes, o utilizador pode compra quantos bilhetes quiser, com quantas viagens desejar, escolher o modo de pagamento, e ainda escolher qual o modo como quer receber estes bilhetes. Tal como na edição de dados, aqui o utilizador também pode cancelar a sua compra.

Após comprar bilhetes, é permitido ao utilizador consultar a sua lista de bilhetes e ver cada bilhete em detalhe, como por exemplo, consultar quantas viagens ainda tem disponíveis em cada bilhete. Nesta secção, existem ainda mais duas abas, uma onde é possível consultar o respetivo histórico (compras, utilização de viagens, autocarros onde andou, etc.), e outra para recuperar bilhetes perdidos ou danificados.Contudo, aquando do preenchimento das forms, não temos a opção de “Undo” (voltar aos valores que lá estavam anteriormente), nem de “Redo”. A única opção é a de, quando o utilizador quer mudar os dados da sua conta, estes aparecerem nos campos já preenchidos, com os valores atuais correspondentes.

4 - CONSISTeNCy ANd STANdARdS (Standardização e Consistência)

O sistema pode-se considerar, de um modo geral, consistente, pois todo o design (labels, botões, mensagens, etc.) segue sempre o mesmo padrão, e a interface apresentada é sempre igual para todos os clientes do serviço.

Existem algumas situações onde dizer que as cores foram bem aplicadas, como por exemplo, botões, mensagens e listagem de bilhetes. Nos botões, fizemos uso da cor azul (bastante usada no mundo real nestas situações), por ser uma cor forte, para dar a entender que aquele botão é para confirmar o desejo do utilizador (registar conta, fazer login, compra bilhetes, etc.), sendo que os botões para cancelar qualquer ação têm a cor branca, pois trata-se de uma cor, quando visualizada ao pé da cor azul, como uma cor menos apelativa, mais discreta. Por seu lado, nas mensagens, tal como mencionado anteriormente, usámos as cores verde e vermelho para transmitir, respetivamente, sucesso e erro, tal como no mundo real. Por fim, na listagem de bilhetes, fizemos igual uso da mensagem transmitida por cada cor para informar, à primeira vista, se um utilizador tem ou não muitas viagens em cada bilhete, ou seja, usamos a cor verde para bilhetes que ainda tenham várias viagens, mas usamos a cor laranja para alertar um utilizador que aquele bilhete apenas tem uma viagem.

Relativamente à semântica associada a um bilhete (forma de validação da viagem), é sempre descrito como um “Ticket” ao longo da aplicação.

5 – eRROR PReVeNTION (Prevenção de Erros)

No que diz respeito a prevenção de erros, consideramos que o nosso serviço tem as proteções devidas. Tal como tem vindo a ser mencionado, os botões de cancelamento têm uma cor adequada em vez de uma cor apelativa e forte, e não têm tanto destaque com os outros botões. Contudo, a nossa maior prevenção de erros encontra-se nas diferentes mensagens de sucesso e erro.

Quando um utilizador se encontra a registar uma nova conta, caso haja campos por preencher ou preenchidos incorretamente, o registo de conta não é feito e as respetivas mensagens de erro são apresentadas, como por exemplo, “First name is required.”; “Invalid email. It must follow the pattern: [email protected].”. Nesta página, de registo, fazemos várias verificações a todos os campos: se estão preenchidos ou não, se seguem os padrões aceites, se escolheu imagem para a fotografia de conta, se o username já existe ou não por outro utilizador, e se as passwords são iguais ou não. Aquando do correto preenchimento dos campos, uma mensagem de sucesso, de cor verde, é apresentada. Assim que um utilizador se regista com sucesso, é-lhe dada a oportunidade de alterar os seus dados quando desejar, sendo que as mesmas verificações aquando do registo são também aqui feitas, e as respetivas mensagens de erro e sucesso aparecem.

Outra situação onde também aparecem mensagens é quando um utilizador tenta fazer login e, por alguma razão, não consegue. Normalmente, se o utilizador não conseguir, é porque o username não existe ou então porque a password não corresponde ao username definido.

Por último, fazemos distinção entre as ações primárias e secundárias de modo a terem o devido destaque. Para tal, basta visualizar a página de registo para observar que “Create Acount” é uma ação primária e “Cancel” é uma ação secundária.


6 – ReCOgNITION RATheR ThAN ReCALL (Reconhecimento em vez de Recordar)

Para este princípio não podemos comentar nem argumentar porque não temos nenhuma situação no nosso serviço onde se possa aplicar.

7 – fLexIBILITy ANd effICIeNCy Of uSe (Flexibilidade e Eficiência de Utilização)

O nosso serviço, no que toca a este princípio, apenas se pode avaliar na usabilidade do nosso serviço e no acesso que permitimos a outros serviços adjacentes ao nosso, pois os shortcuts a que este princípio se refere dizem mais respeito aos próprios Sistemas Operativos e programas de software do que propriamente a páginas Web. No entanto, a página Web foi desenvolvida tendo em vista a forte possibilidade de poder ser consultada em plataformas móveis. Este dado é responsável por grande parte das opções de design tomadas: simplicidade, clareza, informação mais importante em destaque, menor número possível de cliques, menor número de páginas possível (evitando carregamentos que, em ligações fracas ou lentas, atrasariam muito o processo). Adotamos também um “Responsive design”, o que resultou num sistema flexível e eficiente nas várias plataformas.

Quando um utilizador pretende aceder ao nosso serviço, ele pretende, principalmente, comprar viagens e, caso seja um utilizador registado, ver quantas viagens ainda tem. De modo a sermos eficientes, a nossa Homepage tem logo pronta a aba para se poder comprar bilhetes, sendo que, para utilizadores registados, após efetuarem login, além da aba para comprarem bilhetes, é-lhes logo apresentada a aba onde diz quantos bilhetes e viagens têm e onde podem gerir estes.

Quanto à parte a que nos diz respeito, penso que temos o acesso aos serviços adjacentes a serem feitos de uma forma rápida e fácil. Para tal, basta aceder à aba “Services” no menu e escolher uma das opções. As duas primeiras redirecionam os utilizadores para o Web Site dos SMTUC, entidade responsável pelos autocarros que usaram este serviço; a terceira permite aceder ao Web Site da Câmara Municipal de Coimbra, à qual os SMTUC pertencem; por fim, as duas últimas dizem respeito a Web Sites que ajudaram na realização do nosso serviço, a Universidade onde estudamos e a documentação do projeto.

8 – AeSTheTIC ANd MINIMALIST deSIgN (Estética e Design Minimalista)

O nosso serviço pode-se considerar minimalista no que toca a informação, mas esta opção deve-se ao fato de apenas pretendermos dar ao utilizador a informação pretendida. Quando um utilizador acede ao nosso Web Site ele pretende, principalmente, comprar bilhetes, pelo que a nossa Home Page disponibiliza logo essa funcionalidade, tal como foi referido no princípio anterior. Ou seja, não nos preocupámos em fornecer informação sobre nós, dizer quem somos, fornecer os nossos contatos, ou, por outro prisma, quando recebe um email, dizer qual o servidor que mandou e quais os mecanismos de segurança, por exemplo. Concluindo, consideramos o nosso serviço minimalista, esteticamente bem estruturado, e que apenas fornece ao utilizador o que ele pretende, sendo que as restantes funcionalidades estão situadas no cabeçalho/barra de ferramentas, à semelhança de outros serviços (ex. facebook).

9 – heLP uSeRS ReCOgNIze, dIAgNOSe, ANd ReCOVeR fROM eRRORS (Ajudar Utilizadores a Reconhecer, Diagnosticar e Recuperar Erros)

Este princípio está ligado ao princípio 5, Prevenção de Erros, e muito da argumenta-ção foi dada nesse princípio. Tal como mencionado anteriormente, sempre que existe um erro uma mensagem relacionada com esse erro é apresentada ao utilizador, pelo que o nosso serviço tem um bom sistema para ajudar os utilizadores a reconhecer, diagnosticar e a recuperar erros. Através destas mensagens, é possível corrigir os erros e prosseguir.

10 – heLP ANd dOCuMeNTATION (Ajuda e Documentação)

Por fim, no que toca ao último princípio, consideramos que temos um bom sistema de apoio aos clientes, pois temos 3 maneiras distintas de terem ajuda: documentação do projeto, consultar a FAQ, e reportar erros à administração. A documentação do projeto encontra-se na aba “Services” do menu e redireciona o utilizador para a respetiva página, enquanto a FAQ se encontra na aba “Help” do mesmo menu, tal como a possibilidade de reportar erros.


REVISÃO CRíTICA12

A revisão crítica consiste numa forma de argumentar e julgar aspetos considerados importantes sobre um certo tema. Na nossa revisão crítica escolhemos um tópico específico para abordar, sendo que a escolha caiu sobre a HTA (Hierarchical Task Analysis) por ser, para nós, o que mais influenciou na definição e criação do nosso serviço e design do próprio. A HTA é uma análise de tarefas usada para estudar e desenhar interfaces para aplicações comuns.

Uma das grandes vantagens desta análise é o facto de não se focar simplesmente no que o utilizador pode fazer, mas sim no porquê das suas ações e quais as suas finalidades. Uma vez que esta análise tenta compreender as necessidades das ações dos utilizadores, é possível criar uma estrutura de tarefas que está orientada por objetivos. Com estas características, facilmente se transpõe as necessidades do serviço em tarefas singulares ou compostas, obtendo, deste modo, uma hierarquização de tarefas possíveis. A HTA, não só abrange as questões das necessidades, mas também tem em conta questões como quando será a tarefa efetuada, quais recursos serão necessários, que erros poderão ocorrer, entre outros. No entanto, existem algumas desvantagens, passando pela possibilidade de duplicar procedimentos errados ou a falha na aquisição dos bons aspetos dos procedimentos.

Contudo, a HTA poderia ser otimizada, pois poderia existir um catálogo já com alguma descrição de tarefas usuais que podiam ser integrados num ISS. Ou seja, as tarefas que constituiriam o catálogo seriam tarefas que muitas vezes estão presentes num dado ISS, autenticação, pagamento de produtos, ajuda, etc.

Desta forma, aquando da construção da HTA, não se tinha de estar a reescrever todas as tarefas de suporte de um ISS. É certo que podemos não necessitar de ter presentes todas estas tarefas de suporte, mas estas criam uma base sólida na construção de um serviço.A catalogação de certo tipo de aspetos na área dos serviços já não é algo novo, visto que, por exemplo, o ITIL usa catálogos para classificar os serviços.

Sobre o catálogo de tarefas, estas seriam agrupadas por: Bussiness, Operational e Technical, tal como o USLD descreve. A principal vantagem seria dar ao utilizador, não só uma base de tarefas de suporte que estão presentes na maioria dos ISS, mas também fornecer a este classes onde as tarefas se inserem. Assim, se o utilizador

quisesse uma tarefa relativa aos price plans (presente em todos os serviços que envolvem pagamentos), sabia que este estaria na classe de Bussiness.

Os elementos mais importantes a ter numa HTA são as tarefas principais que um utilizador pode fazer no serviço, sendo que depois devem ser apresentadas as sub-tarefas e os requisitos de cada uma das tarefas principais. Ao desenharmos a nossa HTA, as tarefas que apresentamos como principais foram aquelas que consideramos ser as mais utilizadas pelos utilizadores e as tarefas de suporte que mais podem necessitar: registar conta, gerir conta, comprar bilhetes, consultar número de bilhetes e viagens disponíveis, recuperar bilhetes, consultar informação sobre autocarros, e obter ajuda.

O sistema, a nível funcional, pode ser subdividido em processos, que por sua vez são subdivididos em tarefas. Estas tarefas estão presentes na HTA, e todas estas tarefas formam o serviço bTicket (root) como um todo. Desta forma, é possível mapear a root da HTA para um serviço, que a nível funcional é representado como um sistema, que em última análise é subdividido em tarefas.


Através da realização deste trabalho, adquirimos conhecimentos relativos à construção de um ISS (Internet-based Self-Service). Através da identificação das tarefas que estivessem disponíveis para os nossos clientes e da identificação das limitações atuais, começámos a identificar o problema e a pensar nas possíveis soluções que se poderiam construir para resolver o problema. De forma a construirmos um sistema viável, em termos económicos, e para que o seu potencial seja reconhecido por parte dos utilizadores, foi necessária uma análise cuidada acerca da perspetiva do negócio, focando-se principalmente nos participantes, nível do serviço, marketing e questões legais (normas e cláusulas).

Aprendemos também a fazer uma caracterização dos utilizadores adequada, ou seja, é necessário entender quem usa o nosso sistema, como é que o usa e porque o usa, de forma a podermos orientar mais o nosso sistema para aqueles que de facto se vão servir dele.

Aprendemos a responder a estas situações, através da classificação dos utilizadores e da criação de personas, de forma a “simular” a utilização do nosso sistema por parte destas e identificar possíveis “falhas” na nossa projeção mental do serviço. Observámos que fazer inquéritos é também um processo importante, aquando da construção de um ISS, de forma a entender limitações ou gostos gerais por parte dos utilizadores.

Adquirimos conhecimentos importantes relativos à estruturação das tarefas e como estas se organizavam nos vários processos presentes no bTicket. Primariamente foi efetuada uma identificação destas e, posteriormente, foi efetuado uma análise esquemática das mesmas (HTA) para confirmar a validade destas tarefas. Foi ainda simulada a utilização do serviço por parte de uma persona.

Aprendemos a fazer a transformação de um serviço (pensado por nós) para um sistema (ISS), sendo que para isto foi necessário recorrer ao modelo “Service as a System”, que consiste em construir um modelo tendo em conta os clientes, objetivos, as entradas (inputs), as saídas (outputs), os processos, os facilitadores humanos (human enablers), os facilitadores físicos (physical enablers), facilitadores informativos (informatic enablers) e o ambiente. Posteriormente, foi efetuada uma Blueprint que especifica o fluxo de ações e interações executadas pelos utilizadores no serviço.

CONCLUSÃO13Por fim, aprendemos que a utilização de uma framework (no nosso caso django 1.1) que implementa a “design Pattern” MVC torna toda a fase de desenvolvimento muito mais ágil, pois a pessoa (designer) que está a tratar dos aspetos visuais do site (views) pode estar a desenvolver código independente do código da pessoa que está a tratar da parte funcional do site (programador). Desta forma, ambos podem desenvolver as suas partes do trabalho para que ninguém esteja dependente do trabalho de outro.

100 | INTERACÇÃO HUMANO COMPUTADOR

bTicket is a project that intends to improve the experience of using Coimbra’s bus network. This mean of transportation is very important to the city and is one of the most used and chosen by students, tourists, workers, among others.

However, nowadays the ticket purchase and validation at the beginning of the trip is not convenient to users. This project goal is to upgrade these aspects. Using new abilities of computer systems, bTicket simplifies the process and extends the spectrum of use to new digital models. bTicket is a virtual store, where users buy trips and consult bus services and information, like schedules and itineraries. For each purchase a QR Code (Quick Response Code) is assigned; therefore the code is sent to the user via email or MMS. The trip validation is achieved through QRCode scanning (printed or in digital support) through the bus validation interface.

SERVIÇO DE BIHETES DIITAIS PARA OS TRANSPORTES …jcardoso/Services/Concord/bTicket-Service... ·...

Documents

Transcript of SERVIÇO DE BIHETES DIITAIS PARA OS TRANSPORTES …jcardoso/Services/Concord/bTicket-Service... ·...