Sistema de Inscrições TCC-AlexanderCzajkowski-SIU-N2010

7/22/2019 Sistema de Inscrições TCC-AlexanderCzajkowski-SIU-N2010

http://slidepdf.com/reader/full/sistema-de-inscricoes-tcc-alexanderczajkowski-siu-n2010 1/171

UNIVERSIDADE FEDERAL DO PARANÁ

ALEXANDER CZAJKOWSKI

SISTEMA DE INSCRIÇÕES UNIFICADO PARA EVENTOS:

ESTUDO DE CASO DA PROPOSTA DO

N DESIGN IMERSÃO 2010

CURITIBA

2010




SISTEMA DE INSCRIÇÕES UNIFICADO PARA EVENTOS: ESTUDO

DE CASO DA PROPOSTA DO N DESIGN IMERSÃO 2010

Trabalho de Conclusão de Curso apresentadocomo requisito parcial à conclusão do Curso deDesign Gráfico da Universidade Federal doParaná.

Orientadora: Prof a Dra Stephania Padovani

CURITIBA

2010



TERMO DE APROVAÇÃO


SISTEMA DE INSCRIÇÕES UNIFICADO PARA EVENTOS: ESTUDO

DE CASO DA PROPOSTA DO N DESIGN IMERSÃO 2010

Trabalho de Graduação aprovado como requisito parcial para obtenção do grau deDesigner com habilitação em Design Gráfico, do Setor de Ciências Humanas,Letras e Artes da Universidade Federal do Paraná, pela banca composta pelosseguintes professores:

__________________________ Orientador: Prof a Dra Stephania Padovani

Departamento de Design

__________________________ Prof a Dra Luciane FadelDepartamento de Design

___________________________ Prof o Msc. Ricardo Alexandre MartinsDepartamento de Design

Curitiba, 12 de novembro de 2010



Dedico este trabalho a todos os estudantes de

design do Brasil que acreditam e trabalham

voluntariamente em prol de uma causa coletiva,

em especial, à família que encontrei na Conde

Curitiba.



AGRADECIMENTOS

A Professora Doutora Stephania Padovani, Steph, pela paciência sem limites

com seu orientando relapso, e especialmente em admiração à sua postura como

educadora dentro e fora sala de aula, sem dúvidas um modelo a ser seguido.

Aos Professores Ricardo Martins e Luciane Fadel, pelas contribuições e

redirecionamento preciso deste trabalho por ocasião da Banca de Qualificação.

Aos Professores que foram referência positiva durante os 8 anos de minha

graduação: Carla Spinillo, Paulo Reis, Naotake Fukushima, Ken Fonseca, Dubiela,

Bini, Daniella Munhoz, Hiroshi Homma, Sawada. Aos Professores que fora de aulame impressionaram por suas ações: Dulce Fernandes e Ronaldo Corrêa.

Aos colegas que passaram pelo Centro Acadêmico de Desenho Industrial, o

CADI-UFPR, o qual me sinto honrado de ter sido Presidente em 2008 e Colaborador

de 2006 a 2010, e aos colegas representantes discentes, por acreditarem e lutarem

pela construção de uma Universidade mais ágil e produtiva e pela melhoria da

educação, nos meus três anos de Reuniões Departamentais e de Colegiado, um ano

como Conselheiro no Setor de Ciências Humanas, Letras e Artes, e um ano comoConselheiro no Conselho de Ensino Pesquisa e Extensão e Conselho Universitário.

Aos colegas da Conde Curitiba, pela construção do N Design Imersão 2010, o

maior encontro nacional feito por estudantes e para estudantes, do Brasil e do

mundo. E especialmente aos que participaram do desenvolvimento do SIU-N2010,

Gabriella Borges, Marcelo Leite, aos colaboradores Daniel Koganas e Equipe

Sagwee, e a Vinícius Brand, programador que adotou o nosso projeto até o fim.

A Kelli, J ardim, Gui e Martina, colegas da Equipe 10.5, pelos trabalhos maisdivertidos, e aos amigos para todas as horas, Mauro Alex Rego, J anayna Velozo,

Patty Lima, Marina Nicolaiewsky, Anny Venâncio, Priscila Oliveira, Raffaela Loffredo.

A minha irmã, Tatyana (in memoriam), que, mesmo longe, sempre estará perto.

Ao meu pai, minha mãe e meus avós, exemplos de vida, que desde cedo me

incentivaram a buscar sabedoria, lutar e nunca desistir de um objetivo.

Aos meus irmãos, minha família, amigos e amigas, pela confiança e

motivação e compreensão pela ausência involuntária.

A todos que, com boa intenção, colaboraram para a realização e finalização

deste trabalho e aos que não impediram a finalização deste estudo.



“Mergulhe no meio das coisas,

suje as mãos,

caia de joelhos e, então,

procure alcançar as estrelas.”

J ohn L. Curcio



i

RESUMO

Sistema de Inscrições Unificado para eventos é uma proposta realizada pelo N

Design Imersão 2010, que une a inscrição do participante com a submissão de

atividades e outras formas de participação em uma mesma interface, diminuindo a

fragmentação do banco de dados e facilitando a utilização para o usuário. Neste

trabalho será apresentado o processo de design deste sistema e feita uma avaliação

sobre vantagens e desvantagens a partir do feedback do usuário e dos realizadores

do evento.

Palavras-chave: Sistema de Inscrições, Evento, N Design.



ii

ABSTRACT

The Unified Registration System for Conferences is a propose made by the N Design

Imersão 2010. It gathers the participant register process, activities contributions and

another ways of participation in one interface. Thus it reduces the database

fragmentation and makes the user experience easier. This work will present its

design process and an assessment on the advantages and disadvantages based on

the participants and organization board testimonials.

Key-words: Registration System, Conference, N Design.



iii

LISTA DE FIGURAS

FIGURA 01 - Formulário plano antigo.......................................................................15

FIGURA 02 - Formulário contínuo.............................................................................15

FIGURA 03 - Ficha de inscrição de evento dos profissionais de direito....................16

FIGURA 04 - Ficha de inscrição no 4º Congresso Internacional de Design da

Informação..........................................................................................................17

FIGURA 05 - Ficha de inscrição – Vestibular UFPR 2010.........................................17

FIGURA 06 - Ficha de inscrição do 1º N Design – Frente.........................................19

FIGURA 07 - Ficha de inscrição do 1º N Design – Verso..........................................19

FIGURA 08 - Sistema de inscrições do N Design 2010 ............................................20

FIGURA 09 - Desenvolvimento da arquitetura da informação, segundo Garret........24

FIGURA 10 - Modelo simples e elaborado de diagramas do site..............................25

FIGURA 11 - Processo de design..............................................................................29

FIGURA 12 – Banco de dados em sistemas similares ..............................................34

FIGURA 13 – Submissão de atividades em sistemas similares ................................34

FIGURA 14 – Forrmas de pagamento em sistemas similares...................................35

FIGURA 15 – Evento similar com ficha no Word e pagamento por depósito ............35 FIGURA 16 – Similar que utiliza formulário gdocs.....................................................36

FIGURA 17 – Similar que utiliza o sistema SGI.........................................................36

FIGURA 18 - Relacionamento de tabelas por chave-primária...................................46

FIGURA 20 - Interface do pagamento digital.............................................................52

FIGURA 21 - Arquivo de remessa bancária CNAB....................................................53

FIGURA 22 - Comparação entre serviços de webmail..............................................56

FIGURA 23 - Esboços preliminares do SIU...............................................................58

FIGURA 24 - Testes de layout do SIU .......................................................................58

FIGURA 25 - Testes de interface do SIU...................................................................59

FIGURA 26 - Guia de Referência do SIU ..................................................................59

FIGURA 27 - O usuário, a entrada e a saída do SIU.................................................60

FIGURA 28 - Navegação simplificada do SIU ...........................................................61

FIGURA 29 - Seqüência híbrida, com navegação global e local do SIU ...................61

FIGURA 30 - Cinco partes básicas do wireframe do SIU ..........................................63

FIGURA 31 - Detalhamento do design estrutural do SIU ..........................................63

FIGURA 32 – Rascunho do Layout do Menu Superior..............................................65



iv

FIGURA 33 – Layout Finalizado do Menu Superior...................................................65

FIGURA 34 – Legenda do Menu Superior.................................................................65

FIGURA 35 – Diferenciação entre botões ativos e inativos.......................................66

FIGURA 36 – Paleta de cores da interface do SIU....................................................66

FIGURA 37 – Padrão gráfico do site do N2010.........................................................67

FIGURA 38 – Banner do N2010 para o cabeçalho do SIU........................................67

FIGURA 39 – Família tipográfica utilizada.................................................................67

FIGURA 40 – Rascunho final da interface do SIU.....................................................68

FIGURA 41 – Interface final do SIU...........................................................................68

FIGURA 43 - Exemplo de usuário com múltiplos pagamentos emitidos ...................80

FIGURA 44 - Detalhe do diagrama de caso de uso ..................................................90

FIGURA 45 - Exemplos de caixa de alerta................................................................91

FIGURA 46 - Exemplo de feedback após verificação dos campos ...........................92

FIGURA 47 - Exemplo de feedback ao usuário em tela............................................92

FIGURA 48 - Termo de compromisso e caixa de alerta correspondente...................93

FIGURA 49 - E-mail de ativação do cadastro básico ................................................94

FIGURA 50 – Pacote de arquivos enviados para os stakeholders ............................96

FIGURA 51 – Página de exemplo de interface enviada para os stakeholders ..........96 FIGURA 52 – Observação sobre posicionamento dos rótulos do menu superior

feita por um avaliador..........................................................................................97

FIGURA 53 – Correções efetuadas no menu superior do SIU ..................................97

FIGURA 54 – Erros de quebra de linha e curvatura dos botões................................98

FIGURA 55 – Tela inicial do SIU decidida pela verificação de CPF ..........................98

FIGURA 56 – Versão preliminar da ativação de cadastro com código a ser

digitado ...............................................................................................................99

FIGURA 57 – Versão agrupada da página do Passo 3 .............................................99

FIGURA 58 – Análise de métricas do site do N2010...............................................102

FIGURA 59 – Análise de métricas da página de entrada do SIU ............................102

FIGURA 60 – Análise de métricas do SIU por estado.............................................103

FIGURA 61 – Análise de métricas do SIU por navegador.......................................104

FIGURA 62 – Análise de métricas do SIU por suporte a J ava ................................104

FIGURA 63 – Análise de métricas do SIU por resolução de tela.............................105

FIGURA 64 – Resultado QUIS: Idade e gênero......................................................107

FIGURA 65 – Resultado QUIS: Tempo de uso e quantidade de visitas ..................107



v

FIGURA 66 – Resultado QUIS: Quantidade de problemas enfrentados pelo

usuário..............................................................................................................108

FIGURA 67 – Resultado QUIS: Reações negativas ao sistema..............................108

FIGURA 68 – Resultado QUIS: Sistema Unificado é lógico ou ilógico? ..................109

FIGURA 69 – Resultado QUIS: Reações ao Layout...............................................109

FIGURA 70 – Resultado QUIS: Reações à navegação........................................... 110

FIGURA 71 – Resultado QUIS: Sobre a aprendizagem da interface ......................110

FIGURA 72 – Resultado QUIS: Aviso de problemas potenciais.............................. 111

FIGURA 72 – Resultado compilado do atendimento ao usuário .............................122

FIGURA 74 – Exemplo de atendimento com usuário irritado..................................124

FIGURA 75 – Pesquisa de cadastros diretamente no Banco de Dados..................125

FIGURA 76 – Consulta SQL para geração manual de relatórios.............................125

FIGURA 77 – Barra de progressão de ocupação das vagas no Lote 1...................128



vi

LISTA DE TABELAS

TABELA 01 – Análise de similares: encontros nacionais...........................................33 TABELA 02 – Análise de similares: útimos N’s..........................................................37

TABELA 03 - Pacotes, valores, vagas e datas de vigência das inscrições................48

TABELA 04 - Detalhes estruturais dos editais do N2010...........................................50

TABELA 05 - Legenda para das tabelas de dados dos formulários...........................69

TABELA 06 - Login....................................................................................................69

TABELA 07 - Esqueci minha senha...........................................................................70

TABELA 08 - Cadastro básico...................................................................................70

TABELA 09 - PASSO 1: Dados básicos – Seção A (Dados Pessoais)......................70

TABELA 10 - PASSO 1: Dados básicos – Seção B (Local/Contato)..........................71

TABELA 11 - PASSO 1: Dados básicos – Seção C (Formação)................................72

TABELA 12 - PASSO 1: Dados básicos – Seção D (Outros).....................................73

TABELA 13 - PASSO 2: Censo do encontrista..........................................................73

TABELA 14 - PASSO 3: Seleção de pacotes ............................................................78

TABELA 15 - PASSO 3: Forma de pagamento..........................................................79

TABELA 16 - EDITAIS: Campos padrão e invisíveis dos editais ...............................80

TABELA 17 - EDITAIS: Inscrição de atividade Mergulho...........................................81

TABELA 18 - EDITAIS: Inscrição de atividade Quebrando o Gelo ............................82

TABELA 19 - EDITAIS: Inscrição de atividade SEPA ................................................83

TABELA 20 - EDITAIS: Inscrição de atividade Mostra de Vídeo ...............................84

TABELA 21 - EDITAIS: Inscrição de Representante do Cone Design.......................85

TABELA 22 - EDITAIS: Inscrição de Monitor.............................................................85

TABELA 23 - EDITAIS: Inscrição de Chefe de Delegação ........................................88

TABELA 24 - EDITAIS: Inscrição de Bazar................................................................89

TABELA 25 – Estatísticas Finais do SIU-N2010......................................................100

TABELA 26 – Feedback Usuário: Cadastro Básico.................................................112

TABELA 27 – Feedback Usuário: Pagamentos.......................................................113

TABELA 28 – Feedback Usuário: Pacotes..............................................................115

TABELA 29 – Feedback Usuário: Editais ................................................................116

TABELA 30 – Feedback Usuário: Limitações SIU-N2010 .......................................118

TABELA 31 – Feedback Usuário: Dúvidas em geral ...............................................119



vii

TABELA 32 – Feedback Usuário: Erros de sistema ...............................................121



viii

LISTA DE SIGLAS

ADG

AI

BDRs

BDOO

CADI

–

–

–

–

–

Associação Brasileira dos Designers Gráficos do Brasil

Arquitetura da Informação

Bancos de Dados Relacionais

Bancos de Dados Orientadores a Objeto

Centro Acadêmico de Desenho Industrial

CNAB – Centro Nacional de Automação Bancária

CONE

CPF

CSSFEBRABAN

HCI

HTML

–

–

––

–

–

Conselho Nacional dos Estudantes de Design

Cadastro de Pessoas Físicas

Cascating Style SheetsFederação Brasileira de Bancos

Human-Computer Interaction

Hyper Text Markup Language

NDESIGN – Encontro Nacional dos Estudantes de Design

N2010

PDF

PHPPX

QUIS

RG

–

–

––

–

–

N Design Imersão 2010

Portable Document Format

Hypertext Prepocessor Pixel

Questionário de Satisfação do Usuário com a Interface

Registro Geral

SIE – Sistema de Informações ao Encontrista

SIU

SGBs

SPAMSQL

–

–

––

Sistema de Inscrições Unificado

Sistemas Gerenciadores de Bancos de Dados

Sending and Posting Advertisement in MassStructured Query Language

TI

UCD

UFPR

–

–

–

Tecnologia e Informação

Design Centrado no Usuário

Universidade Federal do Paraná



ix

SUMÁRIO

1 INTRODUÇÃO.......................................................................................................11

2 FUNDAMENTAÇÃO TEÓRICA .............................................................................13

2.1 SISTEMAS DE INSCRIÇÕES DE EVENTOS ..................................................14

2.1.1 Definição.................................................................................................14

2.1.2 Histórico dos Formulários.......................................................................15

2.1.3 Estudo de Caso: N Design......................................................................18

2.1.4 Banco de Dados .....................................................................................20

2.1.5 Linguagens de programação..................................................................21

2.2 DESIGN DE INTERFACES DIGITAIS ..............................................................23

2.2.1 Arquitetura da Informação.......................................................................23

2.2.2 Navegação..............................................................................................25

2.3 DESIGN DA INFORMAÇÃO APLICADO À WEB .............................................26

3 DESENVOLVIMENTO............................................................................................29

3.1 PROCESSO DE DESIGN ................................................................................29

3.1.1 Discussão ...............................................................................................30 3.1.2 Criação ...................................................................................................30

3.1.3 Validação................................................................................................31

3.1.4 Conclusão...............................................................................................31

3.2 ANÁLISE DE SIMILARES ................................................................................32

3.2.1 Sistemas de Inscrições de outros Encontros Nacionais de Estudantes..32

3.2.2 Sistemas de Inscrições das últimas edições do N Design......................37

3.3 SISTEMA DE INSCRIÇÕES UNIFICADO DO N DESIGN IMERSÃO 2010 ....39

3.3.1 Apresentação do SIE – Sistema de Informações ao Encontrista............39

3.3.2 Apresentação do SIU N2010 ..................................................................42

3.3.3 Público-alvo ............................................................................................43

3.3.4 Parâmetros, requisitos e restrições ........................................................43

3.3.5 Organização e Informações Básicas do SIU ..........................................45

3.3.6 Desenvolvimento Inicial do SIU ..............................................................55

3.3.7 Design Estrutural e Navegação..............................................................60

3.3.8 Detalhamento da Interface......................................................................65

3.3.9 Detalhamento dos Formulários...............................................................69



x

3.3.10 Detalhamento das Telas .......................................................................89

3.3.11 Diagrama de Caso de Uso....................................................................90

4 VALIDAÇÃO ..........................................................................................................95

4.1 AVALIAÇÃO COM STAKEHOLDERS...............................................................95

4.2 ESTATÍSTICAS GERAIS................................................................................100

4.2.1 Estatísticas Finais dos Cadastros do SIU-N2010 .................................100

4.2.2 Estatísticas de acesso e perfil do usuário.............................................101

4.3 QUESTIONÁRIO DE SATISFAÇÃO DO USUÁRIO COM A INTERFACE......105

4.4 FEEDBACK DE ATENDIMENTO AO USUÁRIO ............................................111

4.5 FEEDBACK DA ORGANIZAÇÃO...................................................................124

5 CONCLUSÕES E RECOMENDAÇÕES..............................................................129

REFERÊNCIAS.......................................................................................................132

APÊNDICES ...........................................................................................................135



11

1 INTRODUÇÃO

Os sistemas de inscrições de eventos acadêmicos, na sua grande maioria,

não prezam por um Design Centrado no Usuário (UCD). Além disso, a

fragmentação de informações, que parte desde a arquitetura do sistema, dificulta

não só o uso, mas também a administração da coleta de dados. Desta forma, o uso

destes sistemas torna-se uma tarefa cansativa e pouco produtiva, o que muitas

vezes afeta a qualidade dos dados coletados, consequência do estresse do usuário.

Estes problemas podem ser ocasionados por falhas projetuais na concepção e

implementação de tal sistema.

Como principais pontos de análise, apresenta-se:

A organização da informação é falha a partir de sua concepção, sendo

bastante fragmentada;

O conteúdo informacional desconsidera a linguagem do usuário e o

feedback de experiências anteriores; e

A apresentação da informação não é feita através de uma mensagemamigável ou de fácil assimilação.

Diante disso, levanta-se o seguinte questionamento: como facilitar o

preenchimento de dados pelos usuários através da unificação de sistemas de

inscrições de eventos?

Como objeto principal desta pesquisa serão analisados sistemas de inscrições

de eventos, focando mais precisamente na vigésima edição do Encontro Nacional de

Estudantes de Design, o N Design Imersão (N2010), que reuniu cerca de 4,5 mil

participantes, sendo o maior evento brasileiro da área e um dos maiores da América

Latina.

Nesta edição do evento foi executada pela organização, com a participação

do autor deste trabalho, uma proposta de unificação do sistema de inscrição do

participante ao sistema de submissão de atividades, com automatização e

acompanhamento em tempo real de estatíticas. O resultado é o Sistema de

Inscrições Unificado do N2010, que será o alvo de análise deste texto.Devido ao porte do evento, considerou-se a oportunidade como ideal para



12

recolher e analisar o feedback do usuário a partir de uma situação real, e não de um

teste de laboratório, uma vez que o sistema existe de fato e foi amplamente utilizado

entre janeiro e julho do ano corrente.

O objetivo geral deste projeto trata de: apresentar o Sistema de

Inscrições Unificado para eventos através do estudo de caso da proposta do N

Design Imersão 2010.

Para alcance do objetivo geral estabelecido, foram determinados os seguintes

objetivos específicos:

a) Comparar sistemas de inscrições das últimas edições do N Design e de

eventos similares;

b) Detalhar o Sistema de Inscrições Unificado, proposto pelo N Design

Imersão 2010;

c) Examinar feedback dos usuários inscritos no sistema proposto pelo N

Design Imersão 2010;

d) Registrar o feedback dos realizadores sobre o sistema de inscrições

unificado para eventos.

Os eventos no Brasil estão em crescimento contínuo, tanto em quantidade depessoas quanto em frequência de realização. Na contramão disso, os sistemas de

inscrições continuam sendo bastante arcaicos, fragmentados e confusos,

dificultando a ação dos usuários interessados, gerando um estresse na execução da

tarefa e chegando a impedir a acessibilidade em alguns casos. Deve-se levar em

conta que estes sistemas são "a porta de entrada" dos interessados na grande

maioria dos eventos.

Além disso, este trabalho poderá servir de plataforma para a construção desistemas similares - em eventos de design e até de outras áreas. Por meio do

Design Gráfico pode-se, por exemplo, aprimorar a qualidade do sistema

informacional, facilitar o uso da interface, promover um design centrado no usuário e

diminuir a sobrecarga de informações em tela. Desta forma, acredita-se que a

contribuição da pesquisa será válida, colaborando com o aprimoramento de novos

sistemas de inscrições.



13

2 FUNDAMENTAÇÃO TEÓRICA

Para a fundamentação teórica deste trabalho serão abordados aspectos de 3

eixos distintos:

Sistemas de Inscrições de Eventos;

Design de Interfaces Digitais;

Design Gráfico Aplicado à Web.

Antes disso, vamos retomar uma reflexão que Flusser aborda em um de seus

artigos, publicado por Rafael Cardoso (2007) no livro Mundo Codificado:

Em Inglês, a palavra design funciona como substantivo e também comoverbo (circunstância que caracteriza muito bem o espírito da língua inglesa).Como substantivo significa, entre outras coisas, “propósito”, “plano”,“intenção”, “meta”, “esquema maligno”, “conspiração”, “forma”, “estruturabásica”, e todos esse e outros significados estão relacionados a “astúcia” ea “fraude”. Na situação de verbo – to design – significa, entre outras coisas,“tramar algo”, “simular”, “projetar”, “esquematizar”, “configurar”, “proceder demodo estratégico”. A palavra é de origem latina e contém em si o ternosignum, que significa o mesmo que a palavra alemã Zeichen (“signo”,“desenho”). E tanto signum como Zeichen têm origem comum,Etimologicamente, a palavra design significa algo assim como de-signar(entzeichnem). Rafael Cardoso (2007, p181)

Para este projeto, antes de tudo, entendemos que o Design é elemento

primordial de um sistema de inscrições, não só pelo apelo estético, interface

eficiente, facilidade de localização, boa arquitetura e ergonomia, mas principalmente

por um fator que anterior ao acabamento e à estrutura: a estratégia. Pensar em um

sistema de inscrições de sucesso é fraudar o óbvio e pensar em como contornaruma tarefa chata em algo mais lúdico, ou pelo menos, menos incômodo. Por trás do

sistema temos um objetivo claro, a conclusão bem sucedida de uma inscrição. No

entanto, temos também objetivos implícitos, como a obtenção de dados necessários

pra “tramar” um evento mais adequado as expectativas do participante, ou a

agilidade na consulta de quaisquer informações do evento pela comissão

organizadora ou pelo participante. Todos estes fatores estão associados ao Design e

contribuem para um bom um sistema de inscrições unificado para eventos.



14

2.1 SISTEMAS DE INSCRIÇÕES DE EVENTOS

2.1.1 Definição

Antes de qualquer coisa, cabe um esclarecimento em termos de

nomenclatura. Neste trabalho será considerado o termo “evento” sendo o

substantivo masculino que denota “acontecimento” ou “ação”, como deslocamento (a

ação) de pessoas a determinada localidade para assistir (o acontecimento) ou

participar, ou palestrar determinado acontecimento.

A reunião de pessoas para um determinado evento é um fenômeno social que

se confunde com a história da humanidade. No entanto, o assunto a ser estudado

aqui não tratará de uma abordagem sociológica, mas sim, de uma pequena parte

técnica relacionada a organização de um evento.

Fato é que, independente dos motivos, a reunião de pessoas em eventos é

algo que se torna cada vez mais freqüente e corriqueiro. Podemos falar de diversos

portes de evento, desde uma reunião familiar até uma feira para centenas de

milhares de pessoas. À medida que os eventos cresceram no seu porte começaram

a ser necessárias ferramentas mais eficientes para organização. Via de regra, em

uma reunião familiar não é necessário cadastrar as pessoas previamente, já que são

poucas informações, porém em uma grande feira onde o número de visitantes

implicará no tamanho do local, na logística contratada, alimentação a ser servida, e

pagamentos de valor variável, por exemplo, aparece a necessidade de um banco de

dados que armazene tudo isso.

Portanto, qualquer evento que necessite tal banco de dados, necessitará

também de um sistema de inscrições, através do qual os dados sejam reunidos.Para a organização, tal sistema atua como este mecanismo de coleta, armazenagem

e administração de informações. Para o usuário, trata-se da maneira pela qual será

assegurada a sua participação no evento em questão, logo, concluindo a inscrição o

usuário confirma seu interesse e garante uma vaga.



15

2.1.2 Histórico dos Formulários

Em épocas anteriores a da criação e popularização da internet já se utilizava

o mecanismo manual, e depois o eletrônico para auxiliar na tarefa de coletar eguardar dados. O formulário foi bastante difundido junto com o crescimento da

necessidade de catalogar dados. Segundo Oliveira (2005), o formulário é um

documento com campos pré-impressos onde são preenchidos os dados e as

informações, que permite a formalização das comunicações, o registro e o controle

das atividades das organizações. O autor acrescenta ainda que existem os

formulários planos, contínuos e eletrônicos, sendo que estes 3 modelos já

demonstram uma certa evolução entre si.

FIGURA 01 - Formulário plano antigo (Fonte: Squidoo)

FIGURA 02 - Formulário contínuo

(Fonte: Gráfica Itabira)

O lançamento de novas tecnologias permite que os campos, antespreenchidos a mão, passassem a ser preenchidos com maquina de escrever.

Depois, para aplicações em larga escala, por longos anos foram utilizadas as

impressoras matriciais para uso com formulários contínuos. Nestes dois modelos de

formulários, por serem físicos, é importante lembrar que ainda existia o fator do

envio dos dados. Considerando que os eventos podem ser em local muito distante, o

envio de tais formulários era realizado através de remessa postal (carta) ou de modo

eletrônico (fax). Recentemente, com a popularização de equipamentos como oscanner e as câmeras fotográficas digitais o envio de um formulário físico de modo



16

remoto se tornou um processo mais rápido e menos custoso.

No entanto, há mais de uma década, com a popularização dos computadores

pessoais e da internet, os formulários eletrônicos já são uma alternativa que oferece

vantagens de anos-luz de distância em relação aos formulários impressos. Exemplo

disso são o menor custo e maior agilidade no processo e especialmente a

catalogação já digital dos dados, possibilitando a edição, acesso e disponibilização

simultânea dos mesmos, algo que até pouco tempo atrás poderia levar semanas,

meses ou até anos, considerando a busca ou análise de informações em grandes

bancos de dados.

Não é de se estranhar a falta de controle das variáveis envolvidas em grandes

eventos, pois a análise dos dados recebidos era muitas vezes inviável, e somente seteria noção real do perfil do público quando o evento já estivesse em curso, tornando

também, muitas vezes, inviável qualquer ação da organização no sentido de atender

melhor ao público em questão.

Estranho é que ainda hoje tantos eventos, inclusive congressos científicos de

médio porte, ainda utilizem sistemas arcaicos e descentralizados para coletar

informações dos inscritos, trazendo ano após ano falhas estruturais graves em sua

execução, algo que poderia ser contornado com o investimento em um sistemaeletrônico centralizado e bem estruturado.

FIGURA 03 - Ficha de inscrição de evento dos profissionais de direito (Fonte: Google)



17

FIGURA 04 - Ficha de inscrição no 4º Congresso Internacional de Design da Informação (Fonte: SBDI)

Um bom exemplo de sistemas que foram modernizados recentemente são as

inscrições dos concursos de vestibular. Até pouco tempo ainda era possível

submeter a inscrição através de formulários impressos, preenchidos a mão e

enviados às instituições de ensino. Atualmente a maioria das grandes Universidades

trabalha apenas com os modelos de formulários eletrônicos centralizados em bancos

de dados bem estruturados. Considerando o Concurso de Vestibular da UFPR, por

exemplo, que reúne cerca de 50.000 candidatos, fica evidente perceber o quanto oprocesso eletrônico não facilita, uma vez que antes muitos dados das fichas eram

digitalizados manualmente, um a um.

FIGURA 05 - Ficha de inscrição – Vestibular UFPR 2010 (Fonte: NC/UFPR)



18

Com o processo digital tornou-se possível o acompanhamento da procura e

concorrência nos cursos em tempo real, assim como a quantidade de candidatos

que farão a prova no local X ou Y, de acordo com a sua preferência indicada no

formulário eletrônico. Pode-se saber ainda, de maneira instantânea, quantos

candidatos estão concorrendo através das cotas de afrodescentes ou quantos são

os estudantes oriundos de escolas públicas, por exemplo. São informações

preciosas que antes demorariam semanas para serem analisadas.

2.1.3 Estudo de Caso: N Design

O N Design, Encontro Nacional de Estudantes de Design é um evento

brasileiro organizado por estudantes e para estudantes que ocorre de maneira

itinerante, tendo uma cidade brasileira diferente como sede a cada ano. A Comissão

Organizadora (CONDE) é formada por voluntários de cada cidade sede, em geral

estudantes universitários dos cursos de design, ou recém-formados.

O evento ocorre desde 1991, quando a primeira edição foi realizada na cidade

de Curitiba-PR. Na ocasião o evento contou com a participação de 700 pessoas.Nesta época os computadores ainda eram para poucos e a internet ainda era algo

com que o brasileiro nem sonhava. A ficha de inscrição era impressa e enviada pelo

correio para as Universidades, através das coordenações de curso ou estudantes já

em contato com a organização. Para efetuar a inscrição o interessado deveria

datilografá-la na máquina de escrever ou preenchê-la com letra de forma, conforme

indica a Figura 07. Feito isso, deveria remetê-la novamente para a comissão

organizadora através do correio, sendo recomendado o uso de carta registrada.

Com o passar dos anos o N Design se tornou um evento de grande porte,

sendo hoje o maior encontro nacional de estudantes do Brasil, reunindo uma média

de 3 mil participantes, considerando as últimas 5 edições. Nestas edições foram

utilizadas diferentes versões de formulários eletrônicos, que serão vistos na Análise

de Similares do item 3 – Desenvolvimento deste trabalho.



19

FIGURA 06 - Ficha de inscrição do 1º N Design – Frente (Fonte: Acervo CADI UFPR)

FIGURA 07 - Ficha de inscrição do 1º N Design – Verso (Fonte: Acervo CADI UFPR)

Em sua vigésima edição, ocorrida em 2010, novamente na cidade de Curitiba,

o N Design reuniu 4547 participantes. Para lidar com tamanha quantidade de dados

foi desenvolvido um sistema de inscrições personalizado, para atender as demandas

do projeto em execução. Este sistema será apresentado em detalhes a partir do

próximo capítulo.



20

FIGURA 08 - Sistema de inscrições do N Design 2010 (Fonte: O autor)

2.1.4 Banco de Dados

Até meados dos anos 60 os dados eram mantidos aleatoriamente em

arquivos, geralmente como partes integrantes da aplicação. A partir dessa época,

surgiram os primeiros Sistemas Gerenciadores de Bancos de Dados (SGBDs)

comerciais, provendo armazenamento dos dados de forma independente da

aplicação (Boscarioli et al, 2006). Este foi o início dos Bancos de Dados Relacionais

(BDRs), aprimorados ao longo das últimas décadas e que hoje oferecem muitas

alternativas de Sistemas Gerenciadores, a exemplo do MySQL, que será visto a

seguir. Os autores discorrem ainda sobre a composição básica de um BDR:

Em BDR, uma coleção de tabelas, todas com nomes únicos, compõem abase de dados, podendo estar relacionada a uma ou mais tabelas.Conceitos como integridade referencial de dados – que garantem que umdado referenciado em uma tabela esteja presente na tabela que está sendoreferenciada – e chaves primárias estão presentes e garantem que umconjunto de informações possa ser representado de maneira consistente,independente da forma de acesso. (Boscarioli et al, 2006)

Além dos BDRs, a partir dos anos 80 surgiram base de dados orientadas a

objetos, para uso em aplicações mais pesadas e com dados fora do padrão



21

tradicional (CHAUDRI & ZICARI, 2001, pg. 3). A capacidade que esse paradigma

possui de representar dados complexos uniu-se à tecnologia de banco de dados,

gerando os Bancos de Dados Orientados a Objeto (BDOO), que suportam

modelagem e criação de dados como objetos (ODBMS, 2006) e não serão

abordados neste trabalho, uma vez que seu entendimento não será necessário para

a análise do Sistema de Inscrições Unificado do N2010.

2.1.5 Linguagens de programação

Existem diversas linguagens de programação que podem ser utilizadas para a

aplicação de um sistema de inscrições. É importante observar que independente dalinguagem, o website deverá ser implementado em linguagem dinâmica, já que o

conteúdo irá variar de acordo com o banco de dados. Se uma linguagem estática for

escolhida, a manutenção do sistema poderá ocasionar em problemas de

administração na atualização dos dados.

Em linhas gerais, em um website estático, todo o conteúdo das páginas é

inserido manualmente por desenvolvedores diretamente no código HTML (HyperText

Markup Language). Esse processo é conhecido como construção da página emtempo de projeto, ou seja, ao mesmo tempo em que o site é codificado tem também

o conteúdo inserido. Sites estáticos não tem sistema de gerenciamento de conteúdo

e são mantidos pelo profissional desenvolvedor, que deve inserir/alterar/excluir

informações do site de forma manual quando necessário (Munzlinger, 2010). Sobre

um website dinâmico, a mesma autora afirma que a atualização de conteúdo torna-

se mais rápida, eficaz e pode ser mantida pelos usuários e administradores do site,

dependendo do profissional desenvolvedor apenas para mudanças estruturais. O

processo pode ser chamado de conteúdo construído on the fly, ou seja, no momento

em que a página é requisitada, são enviadas, buscadas e processadas informações

em um banco de dados, simultaneamente à interpretação e apresentação para o

usuário em seu navegador.

O SIU do N2010, assim como a maioria dos similares analisados, trabalham

com as linguagens PHP e MySQL.



22

PHP: Hypertext Preprocessor

O PHP é apresentado em seu manual colaborativo como sendo “uma

linguagem de programação de ampla utilização, interpretada, que é especialmenteinteressante para desenvolvimento para a Web e pode ser mesclada dentro do

código HTML. A sintaxe da linguagem lembra C, J ava e Perl, e é fácil de aprender.”

(Achour et al, 2010). Segundo Niederauer (2008), o PHP é uma das linguagens de

programação mais utilizadas na Web para a criação de páginas dinâmicas. O autor

explica as principais características que geram esta boa aceitação:

- Gratuito e com código aberto: o PHP é um software livre e com código-fonte

aberto, podendo ser obtido gratuitamente;

- Embutido no HTML: o PHP pode ser misturado livremente com o HTML,

principal linguagem utilizada em websites, gerando um código misto;

- Baseado no servidor: todo o código PHP é executado no servidor,

diminuindo a carga de processamento no computador do usuário e

favorecendo a privacidade do código, uma vez que o mesmo não poderá ser

acessado na íntegra;

- Banco de Dados: diversos bancos de dados são suportados pelo PHP,

trabalhando com a linguagem SQL (Structured Query Language);

- Portabilidade: pode-se executar o PHP em diversos sistemas de servidores,

como Linux, Unix e Windows NT.

MySQL

MySQL é um Sistema Gerenciador de Bancos de Dados relacional que utiliza

a linguagem padrão SQL e é largamente utilizado em aplicações para a Internet(Niederauer, 2008). O autor destaca características como velocidade, escalabilidade

e confiabilidade, tornando o MySQL uma alternativa atrativa, sendo utilizado em sites

com grandes volumes de dados e de tráfego, como Google e NASA. É o mais

popular entre os bancos de dados com código-fonte aberto, sendo utilizado em mais

de 5 milhões de instalações. Algumas vantagens:

- número ilimitado de utilização por usuários simultâneos;

- capacidade de manipulação de tabelas com mais de 50 milhões de registros;

- alta velocidade de execução de comandos;

- fácil e eficiente controle de privilégios de usuários.



23

2.2 DESIGN DE INTERFACES DIGITAIS

2.2.1 Arquitetura da Informação

Sabe-se que a informação não é mais o problema da sociedade atual. O

desafio agora, e cada vez mais, é saber como transformar a informação em

conhecimento. Nesse ínterim, a Arquitetura de Informação (AI) ganha força, assim

como o Ergodesign, aspectos essenciais para o Design de Interfaces Digitais.

O Ergodesign e a Arquitetura da Informação trabalham com osprocessos mentais humanos - os chamados processos cognitivos.Esses processos dizem respeito a como as pessoas aprendem ainformação e como constroem conhecimentos. (Agner, 2009)

Dentro dos Sistemas de Inscrições a AI tem um papel fundamental, pois o

problema pode não estar nas informações que chegam ao usuário, e sim na maneira

como elas foram concebidas e como estão estruturadas.

Rozenfeld e Morville (2002) consideram que AI tem como objetivo organizar

as informações de forma clara, auxiliando as pessoas e maximizando a sua

efetividade. De forma mais específica, Garret (2003) aponta alguns aspectos que

podem ser abordados ao organizar o conteúdo, tais como:

Modos diferentes de atingir uma informação;

Estabelecer relações entre os elementos, gerais e unitários,

Evidenciar as relações do conteúdo visualizado com o conteúdo geral.

Ainda tratando-se de aproximar o usuário das informações, Garret (2003)

sugere uma sequencia de procedimentos. Este modelo possui cinco etapas que vão

das informações mais abstratas às mais concretas, i.e., dos objetivos do site e

necessidades do usuário ao design visual.



24

FIGURA 09 - Desenvolvimento da arquitetura da informação, segundo Garret (Fonte: Garret, 2003)

Pode-se acrescentar a estes procedimentos, cinco etapas propostas por

Maguire (2001), para facilitar a comunicação de um software com o usuário:

- Planejar o processo para um design voltado ao usuário;- Compreender e exemplificar as formas de utilização;

- Identificar o usuário, bem como os requisitos organizacionais;

- Produzir modelos e executar simulações de protótipos e simulações;

- Permitir avaliações do usuário.

Uma AI bem elaborada previne erros comuns de navegação, portanto, Lynch

& Horton (2009) sugerem, para um site elaborado por várias pessoas, um

acompanhamento através de diagramas do site. Assim, cada mudança proposta

deve ser representada nos diagramas, facilitando o planejamento, visualização do

resultado e interação.

Enquanto o site é aprimorado a interação torna-se fundamental para

melhorar o projeto. Vale ressaltar a utilização do design interativo, que se aplicado

aos usuários durante o processo de desenvolvimento, apresenta informações sobre

a repercussão da evolução e as necessidades do público (Maguire, 2001).



25

FIGURA 10 - Modelo simples e elaborado de diagramas do site (Fonte: WebStyleGuide)

Nos diagramas de site mais elaborados estão presentes elementos como a

organização do conteúdo, a profundidade do clique, modelo da página, a estrutura

dos diretórios e de seus arquivos, dados de aplicações, identificação de áreas

restritas, entre outros. Entretanto, a escolha ao adotar o grau de especificidades do

diagrama depende da necessidade, ou seja, se apresentado para um grupo declientes um diagrama simples é suficiente, conquanto não é adequado para a equipe

técnica.

No que tange à equipe técnica, particularmente de designers gráficos, além

dos diagramas, os wireframes serão essenciais para a criação do design e interface

das páginas do site.

Os elementos mais comuns encontrados em wireframe são o logo, a

identidade visual, os títulos das páginas, a navegação, informações de contato,formulário de busca, declarações de direitos autorais, etc.

2.2.2 Navegação

Segundo Norman (1994), navegação é uma metáfora espacial para a

atividade de traçar um roteiro dentro de um sistema hipermídia movendo-se de um

nó para outro. J á Leão (2005) define que navegar, em linhas gerais, é a arte de

encontrar um caminho que leve de local ao outro. A autora ainda lembra que a

complexidade só se viabiliza se existir simplicidade. Isso fica bem evidente em um



26

sistema de inscrições, que por mais completo que seja, deverá ser apresentado ao

usuário de modo que permita fácil navegação, já que ele possui um objetivo

primário: conseguir finalizar sua inscrição, sem perder muito tempo com isso.

Monk (1990) distingue duas estratégias de navegação com base nas metas

informacionais dos usuários: navegação dirigida e navegação exploratória. No caso

do sistema de inscrições a navegação será primariamente dirigida.

Tendo vista que a boa parte dos sites é formada por textos é imprescindível

o conhecimento das regras de composição de acordo com os hábitos de leitura. No

Ocidente cabe o padrão Gutenberg Z, i.e., a leitura é realizada de cima para baixo,

da esquerda para a direita. Os estudos do Instituto Poynter revelaram que para a

leitura de sites, os usuários preliminarmente exploram o canto superior esquerdo,então mantêm o padrão Gutenberg Z para a leitura da página, e por último

digitalizam o conteúdo do lado direito.

Outro fator que merece a atenção é a estrutura informacional do sistema.

Brockman et al. (1989) concluíram que ao mesmo tempo que uma estrutura simples

limita o usuário, ela diminue as possibilidades de desorientação. Os autores

classificam quatro diferentes categorias para sistemas hipermídia: seqüência linear,

grid, árvore e rede.Segundo Padovani e Moura (2008) a definição é hipermídia é: “Sistemas

digitais com arquitetura da informação não seqüencial, os quais incluam múltiplos

formatos de apresentação de informação e permitam ao usuário escolher seus

caminhos dentro do sistema”. No desenvolvimento deste trabalho veremos que a

estrutura informacional de um sistema de inscrições não é necessariamente linear.

2.3 DESIGN DA INFORMAÇÃO APLICADO À WEB

Partindo da grande área temos a definição da Associação Brasileira dos

Designers Gráficos do Brasil – ADG, que diz que design gráfico é “(...) um processo

técnico e criativo que utiliza imagens e textos para comunicar mensagens, idéias e

conceitos, com objetivos comerciais ou de fundo social”. Neste sentido concordamos

com a definição da ADG, pois ela se enquadra no objeto projetual deste trabalho.

Fragmentando subáreas do Design Gráfico aparece o Design da Informação,

que preocupação em transformar dados em informação, tornando aquilo que é



27

complexo mais fácil de compreender e de utilizar (MacLeod, 2003). No entanto,

como estamos falando diretamente de Web, já que o sistema abordado é

inteiramente virtual, não possuí quaisquer peças impressas, necessitamos focar um

pouco mais. Uma definição que interessa então é a de Fleming (1998) que diz que o

visitante do ciberespaço precisa saber: onde está; onde pode ir; como pode chegar

ao local desejado; como pode retornar à posição inicial. Deve-se considerar tanto a

informação disponível propriamente dita, ou seja, o conteúdo, quanto a maneira

como esta informação está organizada. (J ul e Furnas, 1997). Aqui já entramos em

outro campo, de interesse direto para o desenvolvimento de nosso sistema, o Design

da Informação aplicado a Web.

Como trata-se de um ambiente de navegação onde o usuário necessita deorientação, precisamos trazer também uma definição de Wayfinding, o conjunto de

processos perceptivos e cognitivos envolvidos na busca de um destino almejado em

um espaço físico ou informacional. Durante este processo, o indivíduo verifica sua

localização relativa, decide que rota tomar, monitora a rota e reconhece o destino

final (Passini, 1998). Agora, pensando no Sistema de Inscrições, é notável pensar

que o usuário tem um destino almejado, finalizar a sua inscrição com sucesso, e

para isso escolhe uma rota, os formulários de inscrição, depois monitora a rota,aguardando feedback do sistema, e, finalmente, reconhece o destino final, uma

mensagem derradeira assegurando que a sua inscrição foi feita com sucesso.

Segundo Meister (1999) um Sistema pode ser definido como uma entidade

composta de elementos que trabalham juntos (interagem) de modo a atingir um

objetivo que esses mesmos componentes não seriam capazes de produzir

isoladamente. Pensando em Sistema, podemos abordar alguns conceitos que

Padovani & Moura (2008) agrupam, pensando em elementos importantes parafacilitar a navegação do usuário:

Áreas clicáveis;

Mecanismos de auxílio à identificação de áreas clicáveis;

Indicadores de localização;

Ferramentas de auxílio à navegação;

Ferramentas de Retronavegação;

Feedback.



28

Além disso, é necessário que o sistema considere aspectos de prevenção aos

problemas que o usuário poderá encontrar. Aqui, cabe citar um problema

fundamental a ser evitado, a desorientação, que prejudica tanto a usabilidade quanto

a utilidade do sistema (Patel, 1998). A desorientação é também abordada por Foss

(1989), que afirma algumas decorrências ao usuário:

Chegar a um ponto do sistema e esquecer o que foi fazer lá;

Esquecer de retornar de digressões ou de seguir digressões anteriormente

planejadas;

Não saber onde se encontra em relação a outros nós que contenham

informação relevante para a busca;

Esquecer que seções já foram visitadas ou alteradas;

Dificuldade de sumariar que nós de informação já foram consultados após

horas de navegação.



29

3 DESENVOLVIMENTO

3.1 PROCESSO DE DESIGN

Para elaboração do processo de design foi realizada uma pesquisa preliminar,

em diversos sites da web, buscando por modelos apropriados. Da mesma forma,

consultou-se a alguns autores relacionados à HCI (Human-Computer Interface),

como Garrett (2003). Uma vez que os modelos não pareciam corresponder à

abordagem pretendida para o trabalho, o autor optou por iniciar uma nova proposta.

A sequência lógica lembra os processos sugeridos por Vora (1997) e Löbach (2001),

porém foi construída a partir do zero, almejando obter uma maneira possível de

abordar o problema.

A estruturação se dá em um eixo principal, representando as etapas principais

e agrupamentos de sub-etapas de trabalho; suas ramificações, representando sub-

etapas de trabalho; e, suas interligações, representando o seqüenciamento dos

blocos de etapas entre si, conforme demonstrado no diagrama a seguir:

FIGURA 11 - Processo de design (Fonte: O autor)

As etapas principais estabelecidas no processo de design proposto para este

projeto configuram-se como um eixo norteador do processo e, por esse motivo,

serão detalhamente explanadas.



30

3.1.1 Discussão

Na primeira etapa, considera-se a pesquisa de informações básicas

relacionadas ao sistema de inscrições. Inclui-se aqui a revisão de literatura paraconsolidação da fundamentação teórica com os itens de maior relevância para o

desenvolvimento.

Na pesquisa de similares serão analisadas informações de funcionamento

geral de 25 sistemas de inscrições de outros encontros nacionais de estudantes e

também das últimas quatro edições do N Design anteriores ao desenvolvimento do

sistema atual.

Para a análise de público-alvo serão demonstrados dados relativos às últimasedições do N Design e ao final os dados já consolidados da edição de 2010.

Em parâmetros, requisitos e restrições serão apresentados os principais itens

considerados relevantes para o sistema de inscrições pela organização do evento.

São itens fundamentais para assegurar o acompanhamento do desenvolvimento

através de um controle de qualidade.

3.1.2 Criação

Na segunda etapa será relatado processo de criação do Sistema de

Inscrições Unificado do N Design Imersão, começando pelo desenvolvimento

preliminar, incluindo aqui esboços, analogias e os procedimentos adotados até se

obter um sistema possível de ser aprimorado e detalhado nas etapas que seguem.

Em seguida será demonstrado a evolução do design estrutural e

funcionamento básico de navegação no sistema.

O detalhamento da interface abrange a apresentação gráfica final do sistema,

como ele será apresentado ao usuário, o porquê de suas cores, formato dos ícones,

tipografias, e demais elementos de Design da Informação aplicado à Web.

Logo depois todos os formulários serão esmiuçados, montando uma tabela de

cada um deles com as especificações de todos os campos.

Com a integração dos formulários, da interface principal e das páginas de

acesso, passamos, na sequência para o detalhamento de todas as telas visitadas

pelo usuário dentro do sistema de inscrições.

Finalmente, com base nas subetapas acima, passa-se para a apresentação



31

de um diagrama de caso de uso, onde serão apresentadas a integração entre as

telas, rotas dentro do sistema e processos visíveis e ocultos que acontecem no

processamento de cada ação possível do usuário.

3.1.3 Validação

Na terceira etapa aparece o resultado mais esperado do sistema: a sua

utilização, e conseqüentes dificuldades e novos pontos a serem melhorados que

passam a ser descobertos.

A primeira validação foi feita com Stakeholders, antes do sistema ser lançado,

com uma versão beta, distribuída on-line para 80 avaliadores, sendo 60 daorganização e 20 externos.

A segunda foi feita através de modelo adaptado do QUIS – Questionário de

Satisfação do Usuário com a Interface – após 3 meses e meio do lançamento do

sistema de inscrições, visando obter um feedback qualificado daqueles que estavam

se inscrevendo, considerando uma amostra pequena, apenas 20 participantes, já

que o formulário final é bastante extenso, com 63 perguntas fechadas e 7 questões

abertas.A seguir foram analisadas estatísticas sobre como se comportou o sistema de

inscrições durante todo o período pré-evento e durante o evento, considerando a

quantidade de acessos, picos, informações dos usuários, etc, servindo de base para

análises mais aprofundadas e desenvolvimento de novos sistemas.

O próximo passo foi efetuar a compilação e análise do feeback do usuário a

partir dos atendimentos de dúvidas enviadas através de e-mail. Foram avaliadas

todas as mensagens trocadas entre os usuários e a Comissão de TI da Conde

Curitiba, somando um total de 1.000 atendimentos realizados no período entre

fevereiro e julho de 2010.

Por fim, foram compilados os principais pontos apontados pela comissão

organizadora, sempre que um problema relacionado ao sistema de inscrições fosse

detectado.

3.1.4 Conc lusão

Na última etapa, além da sugestão de ajustes feitos com base nas avaliações



32

realizadas com os usuários, serão deixadas contribuições para auxiliar em novos

sistemas que possam ser executados com base no SIU-N2010.

3.2 ANÁLISE DE SIMILARES

O objetivo da análise de similares é mapear como cada sistema lida com

questões básicas operacionais, não focadas em aspectos de design de interface,

mas sim, questões estruturais:

Qual o formato do banco de dados;

Se existe submissão de trabalhos;

Se este envio é unificado ao sistema de inscrições; Se o pagamento é integrado ao sistema;

Qual a forma de pagamento;

Qual o processo para reconhecimento de pagamento;

Qual o sistema utilizado.

3.2.1 Sistemas de Inscrições de outros Encontros Nacionais de Estudantes

Para buscar informações sobre o funcionamento de sistemas de inscrições

em eventos similares foram considerados 25 encontros nacionais de estudantes com

realização no ano de 2010, tal qual o N Design Imersão.

Da amostragem total dos eventos, cinco não puderam ter seus dados

contabilizados, pois estavam fora do ar ou inoperantes, como pode ser conferido na

Tabela 01.

De maneira geral percebe-se que praticamente a metade dos avaliados não

utiliza um armazenamento de dados eletrônico e automático. Nestas, o registro

ainda recorre às fichas de inscrição que devem ser impressas e preenchidas, ou

então enviadas de maneira descentralizada, o que dificulta o processo de inscrição

para o usuário e a administração dos dados pela Comissão Organizadora.



33

TABELA 01 – Análise de similares: encontros nacionais

S I G L A

E d i ç ã o

C u r s o

B a n c o

d e

D a d o s

S u b m i s

s ã o

T r a b a l h

o s

E n v i o

U n i f i c a

d o ?

P a g t o

I n t e g r a

d o

F o r m a

P a g t o

C o m p r o v .

P a g t o

S i s t e m

a

U t i l i z a d

o

1 ENEQUI XXIX Química on-line sim sim não depósito e-mailPKP-OCS

2 ENECO XXXVI Economia on-line sim sim sim pag seguro site SGI

3 ENEEF XXXI Ed. Física e-mail sim e-mail não depósito e-mail -

4 ENEH XXX História gdocs sim e-mail não depósito e-mail gdocs

5 ENEL XXXI Letras on-line sim e-mail não depósito site SGI

6 ENAFISIO VIIFisio-terapia

Word / e-mail sim e-mail não depósito e-mail word

7 ENEAD XXXVIAdminis-tração on-line sim e-mail não depósito e-mail próprio

8 ENECIC XXIVCiênciasContábeis gdocs sim e-mail não pag seguro - gdocs

9 ENESS XXXIIServiçoSocial gdocs não - não depósito e-mail gdocs

10 ENEEEL VEng.Elétrica gdocs sim

e-mail /gdocs não depósito e-mail gdocs

11 ENED XXXI Direito on-line sim e-mail não depósito e-mail próprio

12 ENEG XVIII GeografiaWord / e-mail sim e-mail não depósito e-mail word

13 ENEEn XXXIII

Enferma-

gem

Word / e-

mail não e-mail não depósito e-mail word

14 ENEVET XXIIIMed.Veterinaria impresso não - não depósito - -

15 CONEA LIII AgronomiaWord / e-mail não - não depósito e-mail word

16 ENEB XXXI BiologiaWord / e-mail não - não depósito e-mail word

17 ECEM XL Medicina on-line sim e-mail não depósito site SGI

18 ENEAMB VIIIEng.Ambiental on-line não - sim boleto site próprio

19 ENEF XXXIII FarmáciaWord / e-mail sim e-mail não depósito e-mail word

20 ENEGEO XXXII Geologia impresso sim e-mail não presencial - -21 ENEA XXXIV Arquitetura fora do ar

22 ENEPE XXX Pedagogia fora do ar

23 ENEBD XXXIIIBibliote-conomia fora do ar

24 ENEAP IXAdm.Pública fora do ar

25 ENEMET XEng.Metalúrgica fora do ar

Fonte: O autor.



34

Banco de Dados

71

46

2

0 2 4 6 8

on-linee-mailgdocs

word/e-

impresso

Número de respostas

FIGURA 12 – Banco de dados em sistemas similares (Fonte: O autor)

A maioria dos eventos trabalha com submissão de atividades, porém apenas2 sistemas possibilitam o envio unificado destas durante a inscrição. Entre os demais

a maioria trabalha com envio das fichas através de e-mail, o que novamente

favorece a fragmentação dos dados e aumenta o custo operacional.

Submissão de Atividades

14

6

0 5 10 15

sim

não


Envio Unificado

2

12

1

5

0 5 10 15

sim

e-mail

gdocs

não possui


FIGURA 13 – Submissão de atividades em sistemas similares (Fonte: O autor)

Quanto ao pagamento da inscrição, grande parte ainda trabalha comdepósitos em conta, o que ocasiona falhas e dificulta o controle dos pagamentos já

efetuados, que precisa ser manual, após o recebimento de comprovante de

pagamento por e-mail.



35

Forma de Pagamento

16

21

1

0 5 10 15 20

depósito

pag seguroboleto

presencial


Comprovante de Pagamento

13

4

2

1

0 5 10 15

e-mail

site

não informado

não utiliza


FIGURA 14 – Forrmas de pagamento em sistemas similares (Fonte: O autor)

De modo geral percebe-se que os sistemas similares em outros encontros

nacionais de estudantes são bastante arcaicos, sendo de difícil utilização para o

usuário. Especialmente porque complica a administração de todo o material gerado,

sendo necessário lidar manualmente com centenas ou milhares de fichas de

inscrição e comprovantes de pagamento. Certamente esta é uma escolha

equivocada, dada a disponibilização de tecnologia digital, até de forma gratuita,

como no caso dos formulários do Google Docs®, que poderiam facilitar muito o

processo.

FIGURA 15 – Evento similar com ficha no Word e pagamento por depósito (Fonte: XXXI ENEB)



36

FIGURA 16 – Similar que utiliza formulário gdocs (Fonte: XXXII ENESS)

FIGURA 17 – Similar que utiliza o sistema SGI (Fonte: XXXI ENEL)

Na amostra não foi encontrado nenhum exemplo que se assemelhe, em

questão de aprimoramento de tecnologia, com o que foi aplicado no Sistema de

Inscrições Unificado do N2010, salvo no sistema SGI, um sistema de terceiros,

próprio para eventos, que foi utilizado em 3 encontros analisados. O SGI tem um

propósito semelhante ao SIU, porém é apresentado de maneira mais simplificada.

No geral a grande maioria não se aproxima sequer das amostras de edições

mais antigas do N Design, que será abordado no próximo item.



37

3.2.2 Sistemas de Inscrições das últ imas edições do N Design

Possuir acesso direto aos sistemas recentes utilizados pelo N Design foi algo

pretendido exaustivamente. No entanto, por conta de problemas enfrentados noservidor, em 2009 foram perdidos todos os dados armazenados. Para suprir esta

falta os dados foram coletados através de contato com os organizadores de cada

edição, por meio de questionários ou entrevistas não estruturados. O objetivo foi

preencher a tabela com os mesmos dados que os demais encontros nacionais e

reunir informações específicas sobre problemas e curiosidades.

TABELA 02 – Análise de similares: útimos N’s

E d i ç ã o

S e d e

A n o

B a n c o d e

D a d o s

S u b m i s s ã o

T r a b a l h o s

E n v i o

U n i f i c a d o ?

P a g t o

I n t e g r a d o

F o r m a

P a g t o

C o m p r o v .

P a g t o

S i s t e m a

U t i l i z a d o

N16 Brasília(DF) 2006 on-line sim não sim boleto e

cartão manual próprio

N17Floriano-

polis(SC)

2007 on-line sim não sim boleto arquivo

de lotepróprio

N18 Manaus(AM) 2008 on-line sim não sim boleto extrato

manual próprio

N19 Olinda(PE) 2009 on-line sim sim sim boleto extrato

manualterceirizadoadaptado

Fonte: O autor.

O primeiro dado interessante é que todas as edições do N Design, desde

2006, utilizam um sistema de inscrições desenvolvido ou adaptado para o evento,

com banco de dados próprio, facilitando bastante a administração por parte dosorganizadores, uma vez que estas edições tiveram um público entre 1400 e 4500

participantes cada uma. Nota-se também que nenhum destes sistemas trabalhou

com pagamento via depósito, todos eles possuíam sistema integrado para emissão

de boletos durante o preenchimento do formulário de inscrição.

Com relação à submissão de atividades, nas edições de 2006, 2007 e 2008 o

envio foi realizado a partir de fichas em formato Word. Somente em 2009 foi

efetuado o envio através do sistema de inscrições, com informações pessoaisrecuperadas do banco de dados da inscrição do participante, mas ainda sem



38

submissão totalmente unificada, pois o procedimento administrativo de avaliação e

resultado das atividades aprovadas ou reprovadas era feito manualmente, e não

pelo sistema.

Com relação ao reconhecimento de pagamentos efetuados, somente em 2007

foi utilizado um sistema totalmente integrado com o sistema bancário, a partir de

arquivos de lote com dados da remessa bancária, que eram baixados diariamente e

depois inseridos no sistema do evento, atualizando de modo automático a situação

dos participantes pagantes. Nas demais edições a confirmação de pagamento do

participante era atualizada de forma integralmente ou parcialmente manual, pelos

organizadores a partir de comparação com o extrato bancário. Não era solicitado

que os participantes enviassem os comprovantes de pagamento por e-mail, tal qualainda é feito em boa parte dos encontros nacionais similares.

N Design Brasília 2006 (2400 participantes)

O sistema possuia a possibilidade de pagamento parcelado no cartão de

crédito, além do boleto. Nesse caso era utilizado um sistema próprio da

administradora de cartão de crédito, porém informações sobre a integração entre os

sistemas não foram fornecidas. Uma curiosidade informada é que houve um bug a

partir do milésimo boleto gerado, quando a partir de então todos os boletos foram

gerados com o mesmo número (999), causando um caos entre aqueles que emitiram

e tentaram pagar títulos duplicados.

N Design Flor ianópol is 2007 (4532 participantes)

O responsável relatou que o principal problema encontrado foi a

inconsistência dos números de pacotes com pagamento confirmado informado no

sistema para organização, fazendo com que mais pessoas do que o previsto

chegassem ao evento com uma determinada seleção de pacotes. Por pouco o

ocorrido não quebrou a margem de segurança e o problema de superlotação foi

resolvido com bom-humor e um pouco de paciência de todos.

N Design Manaus 2008 (1400 partic ipantes)

Nesta edição ocorreu uma incompatibilidade entre o sistema bancário e o



39

sistema do evento, fazendo com que muitas confirmações e ações da organização

fossem prestadas de modo manual. Posteriormente, o ocorrido dificultou a prestação

de contas, pois os valores das transações efetuadas foram perdidos.

N Design Pernambuco 2009 (1900 participantes)

O sistema utilizado foi adaptado a partir do sistema “Mesmo”, uma proposta

lançada, no ano anterior, por um participante com experiência em banco de dados. O

sistema Mesmo consistia em utilizar um banco de dados único para todos os

eventos estudantis de design (nacionais e regionais), de modo que o participante

regular precisasse apenas atualizar seus dados, e não preencher um formulário

novo a cada edição. A proposta foi considerada boa por todos, mas diante das

necessidades de adaptação do sistema para o N Design PE, ocorreram muitos

atrasos e pontos não finalizados, ocasionando, por exemplo, o processo não

automático de confirmação de pagamentos. Estes foram alguns motivos que

ocasionaram a não continuidade do sistema em 2010. Entretanto, esse é o que mais

se aproxima do SIU-N2010, sendo uma das principais referências consultadas no

momento da criação. Outra questão pertinente é que em 2009 foram utilizadas

estatísticas simultâneas quanto ao andamento das inscrições para um melhor

planejamento do evento, o que, segundo os organizadores consultados, foi de

grande valia para o desenvolvimento das atividades.

3.3 SISTEMA DE INSCRIÇÕES UNIFICADO DO N DESIGN IMERSÃO 2010

Neste item do trabalho serão detalhados todos os fatores relacionados ao

Sistema de Incrições Unificado proposto pelo N Design Imersão, desenvolvido com o

objetivo de solucionar problemas recorrentes encontrados nos similares e, sendo o

escopo principal aperfeiçoar e otimizar o aproveitamento do sistema de inscrições

para garantir o êxito do evento organizado.

3.3.1 Apresentação do SIE – Sistema de Informações ao Encontr ista

Precedente a apresentação do SIU é necessário comentar brevemente sobre



40

o Sistema de Informações ao Encontrista – SIE, proposta guarda-chuva do N Design

Imersão 2010 que abarcou a maioria dos itens em desenvolvimento em relação à

Tecnologia e Informação do Encontro.

Aproximadamente 9 meses antes do evento iniciou-se o desenvolvimento do

SIE, fortemente ligado a proposta defendida de Projeto Verde – promover um

encontro gerando o menor impacto ambiental possível. O desenvolvimento ficou a

cargo da Comissão de Tecnologia e Informação (TI) da CONDE Curitiba, formada

pelos membros Alexander Czajkowski (estudante da UFPR e também autor do

presente trabalho), Gabriella de Campos Borges (estudante da PUC-PR) e Marcelo

Leite Ribeiro (estudante da UTP), além de diversos colaboradores internos e

externos à equipe.

Objetivos do SIE:

Desenvolver um sistema informacional eficiente para o evento;

Proporcionar a construção coletiva através da tecnologia;

Promover a inclusão social e a democratização do conhecimento;

Substituir suportes gráficos por tecnologia digital; Diminuir o impacto ambiental gerado com o evento;

Adequar o evento ao perfil do encontrista.

Propostas do SIE:

a) Ilhas de Interação: Telas interativas espalhadas pela cidade-evento com

mapa 3D, mini-eventos, utilidades, votação, informações completas e

atualizadas das atividades, diminuindo a quantidade desnecessária de

materiais impressos;

b) Sistema de Mini-eventos: Possibilidade de qualquer participante criar e

divulgar sua atividade espontânea durante o evento, através das Ilhas de

Interação;

c) Sistema de Inscrições Unificado: Todas as modalidades de inscrição dos

participantes, das atividades e também na centralização de um banco de

dados para possibilitar as Ilhas de Interação e controle por código de barra;



41

d) Censo do Encontrista: Mapeamento de informações sócio-econômicas,

políticas e educacionais dos participantes, a partir do sistema de inscrições,

captando dados para tornar o evento mais inclusivo e coerente com a

demanda do público;

e) Pulseiras com Código de Barra: No momento do credenciamento cada

participante recebeu uma pulseira de PVC, que permaneceu lacrada em seu

pulso durante os dias do evento. Esta pulseira possuía informações

cromáticas (que diferenciavam os tipos de participantes), informações

impressas (pacotes do evento adquiridos) e uma plaqueta de código de barra,

de número único e associado ao cadastro de cada participante;

f) Certificado com horas reais: Todas as atividades foram controladas com

leitores de código de barra, com isso os participantes recebiam as horas em

seu cadastro e no final do evento o certificado impresso indicava as horas

reais de participação;

g) Mapas de Rota, Wayfinding e Sinalização: Desenvolvimento de material

impresso e digital que auxiliava na localização do participante durante o

evento, através de mapas, esquemas, placas e totens.h) Transmissão Simultânea: Algumas atividades por dia com transmissão

em tempo real através da internet (Canal N TV), tornando possível a

participação daqueles que não estavam presencialmente no local do evento;

i) Rádio N FM: Canal de rádio comunitária do N Design, com programação

musical, notícias e novidades do evento, a partir de rádio FM, para os locais

das atividades ou sintonizável no celular e mp3 player;

Das propostas apresentadas acima, a sua totalidade foi executada com maior

ou menor grau de sucesso, com exceção da Rádio N FM que não foi transmitida em

ondas FM devido a problemas de ordem técnica com a montagem final da estação

de transmissão.

O Sistema de Inscrições aparece notavelmente nos itens C e D, porém todos

os itens de A até F dependiam do Banco de Dados por trás do Sistema de Inscrições

para funcionar plenamente. Ou seja, o sucesso da maior parte do SIE, um dos

principais investimentos do N Design Imersão 2010, esteve intimamente conectado a



42

qualidade do SIU, motivo pelo qual estes itens foram brevemente apresentados

neste capítulo.

Algumas informações adicionais sobre o SIE podem ser obtidas no site do

N2010: http://ndesign.org.br/2010/evento/sie/

3.3.2 Apresentação do SIU N2010

O Sistema de Inscrições Unificado (SIU) foi um dos primeiros itens

desenvolvidos pela Comissão de TI da Conde Curitiba, visando a demanda da

abertura das inscrições para os interessados em participar do N Design Imersão,

que foi realizado em prazo mais prolongado que o normal, abrangendo os 6 meses

anteriores ao evento.

Além de fazer um formulário de inscrição eletrônico, o objetivo era criar um

Banco de Dados bem estruturado que possibilitasse a utilização dos mesmos no

Sistema de Informações ao Encontrista. Por isso, desde o início todos os

brainstormings realizados giraram em torno da criação de um sistema unificado e o

mais automatizado possível.

Sistema Unificado

A nomenclatura “unificado” é utilizada para este sistema devido ao fato de

somar-se a diversos formulários relacionados à inscrição do N Design em uma

mesma interface de acesso e em um mesmo Banco de Dados, através de tabelas

relacionadas com chaves primárias. Este foi o meio encontrado para organizar de

modo mais estruturado as informações relacionadas ao evento. Fazem parte do SIU

os seguintes formulários:

Dados Básicos do Participante (PASSO 1);

Censo do Encontrista (PASSO 2);

Escolha de Pacotes e Formas de Pagamento (PASSO 3);

8 Formulários para submissão de diferentes atividades (EDITAIS).



43

3.3.3 Público-alvo

O público-alvo do SIU é composto por jovens na faixa etária de 17 a 25 anos,

sendo praticamente 2/3 com rendimentos familiares acima de 5 salários mínimos,portanto dentro da Classe Média e Classe Média Alta. Os participantes estão

igualmente distribuídos entre os sexos, e a distribuição geográfica abrange todo o

território nacional, porém, mais concentrado nas regiões sul e sudeste, seguidas da

centro-oeste e com menor participação, nordeste e norte. Estas informações foram

consideradas a partir de dados preliminares divulgados pela organização do evento

nos últimos anos e agora, após a realização do N2010, podem ser confirmadas com

base em informações do seu próprio Censo.

Nota-se ainda que os participantes eram formados por 88% estudantes,

sendo 61% de Universidades Públicas e 39% de Universidades Particulares. Os

dados são do Centro do Encontrista do N2010, preenchido por mais de 5.000

participantes no momento da Inscrição.

3.3.4 Parâmetros, requisi tos e restrições

Algumas definições foram impostas pela Comissão de TI para o

desenvolvimento do SIU:

a) Compatibilidade: O sistema deveria ser compatível com os principais

navegadores disponíveis no mercado (Internet Explorer, Mozilla Firefox,

Google Chrome e Safari);b) Velocidade de acesso: A interface deveria ser leve, evitando animações ou

gráficos pesados, primando por um carregamento rápido mesmo em

conexões mais lentas;

c) Estabilidade: O servidor deveria oferecer condições para que o sistema

permanecesse online, praticamente sem interrupções, salvo em

manutenções agendadas;

d) Segurança: O banco de dados deveria protegido contra acessos indevidos,protegendo os dados depositados pelos usuários;



44

e) Grande Fluxo de Acesso: O sistema deveria estar preparado para

comportar milhares de conexões simultâneas, conforme ocorre nas vésperas

do evento ou em datas de deadlines das inscrições;

f) Atualizações do usuário : O sistema deveria permitir a atualização dos

dados do usuário sempre que necessário, com exceção de dados primários

(ex.: CPF e Nome);

g) Automatização: Os limites de cada lote de inscrições e quantidade de

vagas disponíveis deveria ser controlado de maneira automática pelo

sistema, oferecendo feedback sobre as vagas disponíveis para o usuário;

h) Administração: Os administradores do sistema deveriam ter acesso a um

painel controlado, restritivo por usuário e senha, para análise e julgamento

de editais e outras liberações de casos especiais;

i) Relatórios: O sistema deveria fornecer no painel administrativo, relatórios

em tempo real sobre o andamento das inscrições e principais indicadores do

interesse da organização;

j) Integração: Os sistemas de pagamento deveriam estar interligados com o

sistema de maneira automática, reconhecendo os pagamentos já efetuados

e liberando a inscrição ao usuário;

k) Comunicação: O sistema deveria dispor de um mecanismo de comunicação

com o usuário, através de grupos de envio de mensagem personalizados;

l) Status on-line: O usuário deveria ter acesso em tempo real ao status do

andamento da sua inscrição ou submissão de edital;

m) Proteção jurídica: O Termo de Compromisso do evento deveria ser

visualizado e concordado pelo usuário no momento do preenchimento do

formulário, assim salvaguardando a organização de problemas jurídicos

frente a possíveis ocorrências.

Para a maioria dos itens acima foi alcançado êxito, e aqueles que

apresentaram problemas serão tratados em detalhes durante o desenvolvimento

deste trabalho.



45

3.3.5 Organização e Informações Básicas do SIU

Preliminarmente ao desenvolver da estrutura, navegação e interface do SIU é

necessário compreender alguns detalhes que estão por trás do sistema:

a) Login: Cada usuário é identificado e cadastrado a partir de seu número de

Cadastro de Pessoa Física (CPF), documento pessoal e intransferível, válido

em território nacional através de um padrão único de numeração, com 11

dígitos, que possibilita um algoritmo de verificação de autenticidade e que

aqui é utilizado na versão somente números, sem pontos ou traço. (Ex.: CPF

000.111.222-33 > No SIU vira CPF 00011122233);

b) Senha: Cada usuário cria uma senha pessoal de 4 a 15 dígitos que em

conjunto com seu CPF será a forma de acesso ao SIU. A senha não pode ser

alterada pelo usuário, apenas recuperada a partir do e-mail cadastrado.

c) E-mail: Cada usuário cadastra um e-mail pessoal através do qual será feita

toda a comunicação do sistema e da organização com ele. O cadastro

necessita ser ativado através do e-mail informado, justamente para garantir

que o mesmo foi informado corretamente, não prejudicando etapas futuras.

d) ID (Chave-Primária): Cada usuário fica associado em cada tabela do

banco de dados a uma chave-primária auto incrementável, aqui denominada

ID. A primeira ID é vinculada na tabela usuário, portanto a IDUSUARIO passa

a ser a principal referência ao cadastro efetuado. Este número não é exibido

ao usuário, porém é utilizado para associá-lo a qualquer outra informação no

banco de dados.

e) Código de Barra: Durante o credenciamento do evento cada participanterecebe uma pulseira que tem um número único formado por 4 dígitos, na

versão numérica e em formato de código de barra. Este número é gravado no

banco de dados associado a sua IDUSUARIO, e será utilizado durante todo o

evento, para qualquer ação do usuário (ex.: registro de horas de atividades,

consulta de dados pelo usuário ou organização, ticket de alimentação e

retirada de certificado)



46

O banco de dados do SIU armazena, na verdade, centenas ou até milhares

de informações para cada usuário. Seria impossível manter isso organizado sem

diretrizes bem delimitadas e números únicos de referência. Se tudo estivesse numa

mesma tabela, milhares de dados para milhares de usuários não daria certo, assim

como se cada dado fosse associado a um campo ou valor não padronizado, como é

feito, por exemplo, numa anotação manual, que não segue o rigor formal. Facilmente

as informações seriam perdidas e o banco de dados permaneceria corrompido.

FIGURA 18 - Relacionamento de tabelas por chave-primária (Fonte: IceFusion)

Assim, os principais campos para o usuário são: CPF, e-mail e senha, nessa

ordem, e durante o evento, o Código de Barras passa a ser primordial, seguido do

CPF, para casos de troca ou imprevistos associados ao código de barra. J á para a

organização, os principais campos são IDUSUARIO, CPF e e-mail, nessa ordem, e

durante o evento, também passa a ser o Código de Barras como principal, seguido

do CPF e IDUSUARIO.

Os demais campos dos formulários e banco de dados podem ser conferidos

em detalhes no subi tem 3.3.8 deste trabalho.



47

Opções de inscrição

Havia várias possibilidades de inscrição no N Design Imersão, sendo que

todas elas precisavam estar adequadamente previstas para pleno e automáticofuncionamento do SIU. Podemos agrupá-las em Pacotes e Lotes.

a) Pacotes:

Inscrição Básica – Pacote obrigatório, que envolvia todas as atividades

políticas, acadêmicas, científicas e culturais realizadas durante os 8 dias

do evento, das 9 horas às 22 horas, conforme grade de atividades. Incluia

ainda o “Kit do Encontrista”, composto de vários itens promocionais doevento (Bolsa, Camiseta, Caneca, Caneta, Bloco de Anotações, Guia do

Encontrista, Mapa da Cidade-Evento, Revista ABC Design e 2

preservativos).

Al imentação – Pacote opcional, que dava direito a 7 refeições durante o

evento, sendo 1 jantar e 6 almoços, com serviço de Buffet completo e

opções vegetariana e não vegetariana.

Alojamento – Pacote opcional, que dava direito a 8 dias de espaçoindividual de 5m2 no camping coberto (cada participante levou a sua

própria barraca). O pacote incluia ainda segurança, emergência médica,

banheiros, chuveiros com água quente e demais itens de infra-estrutura

básica relacionada ao alojamento.

Festas – Pacote opcional, que dava direito ao ingresso em 7 festas

exclusivas do evento.

b) Lotes: Tradicionalmente o pacote de inscrição básica é dividido em vários

lotes. Cada lote tem uma quantidade de inscrições disponíveis e um período

para compra. Assim, quem comprar antes paga menos e quem comprar

depois paga mais. No N2010 as inscrições foram distribuídas em 3 LOTES

antecipados e 1 LOTE PRESENCIAL.



48

FIGURA 19 - Grade de atividades do N Design Imersão (Fonte: Conde Curitiba)

Cruzando os pacotes e lotes com informações sobre quantidade de vagas,

valores e datas, chegamos à Tabela 03.

TABELA 03 - Pacotes, valores, vagas e datas de vigência das inscrições

PACOTE VALOR VAGAS INÍCIO FINAL

LOTE 1 R$65,00 1500 20/01 31/03

LOTE 2 R$85,00 1500 01/04 15/05

LOTE 3 R$105,00 2000 16/05 28/06

I N S

C R I Ç Ã O

B Á S I C A

PRESENCIAL R$140,00 300 11/07 18/07

ALIMENTAÇÃO R$35,00 3500 20/01 28/06

ALOJ AMENTO R$40,00 3500 20/01 28/06

I N S C R I Ç Ã O

O P C I O N A L

FESTAS R$30,00 3500 20/01 28/06

Fonte: O autor.

Data final ou limite de vagas, o que ocorrer primeiro : O sistema deve

acompanhar automaticamente as variáveis “data final” e “vagas”, e limitar o pacote

ou lote para o que ocorrer primeiro.



49

É importante ressaltar que durante o período de inscrições algumas

mudanças ocorreram, com a inclusão de pacotes opcionais avulsos. Também

ocorreu a prorrogação de todos os prazos fixados em 28/06 para 06/07, devido a um

número de inscrições menor que o previsto no prazo do LOTE 3.

Inscrição de Editais

O N2010 foi um evento com cerca de 400 atividades, de mais de uma dezena

de modalidades diferentes. Boa parte destas atividades foram propostas enviadas

pelos participantes e aprovadas pela organização, que em troca ofereceu uma

categoria de isenção correspondente aos aprovados. Somando editais de atividadescom outros tipos de editais, eram ao todo 8 possibilidades de inscrição,

demonstradas a seguir a partir da chamada realizada no site do N Design Imersão

2010 (http://www.ndesign.org.br/2010/editais):

Representante no Cone DesignVenha fazer a diferença sendo representante de sua universidade nasReuniões do Conselho Nacional dos Estudantes de Design!

MonitoriaVenha ser o braço direito da Conde Curitiba durante o N Design Imersão!

MergulhoCompartilhe seu conhecimento com os demais promovendo algumaatividade que gerará um resultado teórico/prático depois!

Chefe de DelegaçãoSeja organizador de um grupo de sua região e traga seus amigos para o NDesign Imersão!

SEPADemonstre um trabalho acadêmico através de um banner ou de umaapresentação!

Quebrando o GeloPromova uma atividade lúdica ou sobre a PNU para iniciar bem o seu dia!

Mostra de VídeosMostre aquele vídeo produzido por você com tanto empenho!

Bazar O bazar é um espaço de exibição e comercialização de produtos de design,feito por estudantes de design e áreas afins de todo o Brasil.

(CONDE CURITIBA, 2010)



50

Para a estrutura do SIU os Editais influenciam em alguns fatores,

demonstrados na Tabela 04.

TABELA 04 - Detalhes estruturais dos editais do N2010

ISENÇÃO

EDITAL

MAX.

VAGAS

QTDE

P/ ID*INI-CIO FIM Básica Alimentação Alojamento Festas

Cone - 1 08/02 11/07 100% 100% 100% 100%

Monitoria 150 1 08/02 11/04 100% 100% 100% 100%

Mergulho 150 3 08/02 11/04 100% 100% 100% -

Delegação - 1 08/02 15/05 100% 100% 100% -

SEPA 68 3 08/02 11/04 100% - - -

Mostra - 1 08/02 11/04 50% - - -

QuebraGelo 18 3 08/02 11/04 50% - - -

Bazar 20 1 08/02 30/04 - - - -

* QTDE P/ ID: Quantidade máxima de submissões por IDUSUARIO.

Fonte: O autor.

Para avaliação das editais submetidos existia uma interface administrativa

onde a Conde Curitiba poderia aprovar ou reprovar cada proposta. Uma vezaprovada, o usuário passava automaticamente a ter o direito de finalizar sua

inscrição com a isenção correspondente, pagando a diferença a partir da sua

seleção de pacotes, se necessário. No caso de várias aprovações para o mesmo

usuário, valia unicamente a isenção mais abrangente. Todos os usuários que

submeterem uma proposta de edital tinham a garantia de se inscrever nos valores

relativos ao LOTE 1 por até 2 semanas após a divulgação dos resultados de seu

edital, independente do LOTE VIGENTE, assim como possuía neste prazoassegurada a vaga nos pacotes opcionais, mesmo na hipótese do esgotamento

destes. Essa medida visava garantir que o concorrente a um edital não necessitasse

dispender a quantia equivalente para assegurar sua vaga antes do resultado da

seleção, evitando uma troca de valores desnecessária para ele e para a

organização, que depois teria que reembolsá-lo.

Verif icação de Variáveis e Duração da Sessão

Quando o usuário se conectava ao sistema através do login era feita uma



51

primeira verificação, relativa ao andamento dos lotes, vagas, datas e afins. A

condição encontrada era válida para toda a sessão. Por exemplo, se o usuário se

conectava ao sistema às 23:50 horas do dia em que se encerram as inscrições, ele

conseguiria fazer a inscrição até às 01:49 do dia seguinte, pois a sessão tinha

validade por 120 minutos, salvo se o usuário fizesse o logout.

Forma de Pagamento

A forma de pagamento foi um assunto bastante discutido dentro da Conde

Curitiba, alvo de extensas reuniões de análise das opções possíveis. Isso antes

mesmo do assunto atingir a Comissão de TI. Muitos fatores estão relacionados aqui,

e os principais são financeiros, já que em relação a parte técnica existe uma certa

similaridade entre os serviços oferecidos.

Havia o objetivo de oferecer opção de parcelamento aos usuários, porém a

necessidade de não correr risco de calote nas prestações intermediárias. Aqui

aparece a preocupação financeira e técnica, uma vez que só se poderia confirmar a

inscrição com sucesso de um usuário caso ele já tivesse pagado todas as parcelas.

Portanto, a opção de carnê logo foi descartada, seguida do contrato direto com uma

operadora de cartão de crédito, pois estas exigem maior movimentação e períodos

maiores para o contrato do que a duração das inscrições.

Restaram então os dois principais serviços de pagamento que se encontram

na internet brasileira na época: Pag Seguro da UOL e Pagamento Digital do

Buscapé. Atualmente estão ganhando mercado também o MOiP e o f2b. Entre os

dois primeiros optou-se pelo Pagamento Digital, em especial pelo custo ligeiramente

mais baixo. O mais interessante destes sistemas é que eles oferecem apossibilidade de integração automática entre os sistemas, ou seja, cada pagamento

confirmado no sistema deles passa a ser reconhecido pelo sistema do N Design

2010, e instantaneamente o usuário já visualiza no SIU o seu pagamento confirmado

e mensagem de boas-vindas ao evento. O Pagamento Digital oferece também bons

gráficos com resumo das transações efetuadas e a listagem de todas elas com os

detalhes e possibilidades de ação no painel administrativo. Todas estas facilidades

não ocorrem na compensação bancária convencional.



52

FIGURA 20 - Interface do pagamento digital (Fonte: O autor)

Porém, naturalmente, o serviço envolve um custo, que no caso é repassado

integralmente ao usuário. Para pagamentos no cartão de crédito, sem parcelamento,é cobrada uma taxa de 6,39% sobre o valor da transação. No caso de uma inscrição

completa, no LOTE 1, no valor de R$170, a taxa seria de R$10,86. Caso este

usuário ainda desejasse parcelar, seria acrescida a taxa de 1,99% ao mês. No

mesmo exemplo acima, uma compra parcelada em 4x teria parcelas de R$48,70 e

valor total de R$194,80, um acréscimo de R$24,80, quase 15% do valor original da

inscrição gastos em taxas, valor despendido pelo usuário. Assim, o valor final

cobrado do usuário variava de acordo com a seleção de pagamento, e a CondeCuritiba recebia sempre o valor original da seleção de pacotes.

Pelas facilidades de pagamento centralizado e integração entre os sistemas,

cogitou-se manter o pagamento à vista por boleto associado ao Pagamento Digital.

Porém, nesta opção de pagamento a taxa cobrada seria de 2,89% sobre o valor da

transação. No mesmo exemplo acima, para um boleto de R$170,00 o usuário

pagaria uma taxa de R$4,91. J á em negociação com o Banco HSBC, foi conseguiu-

se uma taxa fixa de R$2,50 por boleto, tornando esta alternativa mais interessanteque o Pagamento Digital, que só teria uma taxa abaixo de R$2,50 se o valor da

transação fosse abaixo de R$115, uma minoria dos casos.

Assim, os pagamentos em boleto passaram a ser feitos a partir de integração

bancária com o HSBC. O funcionamento é um pouco distinto, pois neste caso havia

necessidade da geração do boleto não registrado direto no servidor do N Design

Imersão 2010, sem comunicação com o HSBC. Uma vez que o título fosse

compensado, o sistema bancário creditava o valor diretamente na conta do banco edisponibilizava um relatório codificado com os pagamentos realizados, valores,



53

datas, etc. Este arquivo utilizava um padrão de remessa bancária, chamado CNAB

(Centro Nacional de Automação Bancária) segundo regras da FEBRABAN

(Federação Brasileira de Bancos). Diariamente era necessário verificar junto ao

banco se existia um novo arquivo de remessa, baixá-lo e fazer o upload dele na

interface administrativa do SIU, que interpretava o código, reconhecia pagamentos

efetuados com sucesso e dava baixa ao usuário, confirmando sua inscrição. Este

processo é mais trabalhoso, tanto na criação do sistema, pois a interface

administrativa precisava ser feito pelos organizadores, enquanto no Pagamento

Digital já estava pronto, como na manutenção, exigia uma rotina diária de

atualização. Além disso, o usuário não tinha o retorno instantâneo de sua inscrição

confirmada após o recebimento do banco. Este retorno estava relacionado aomomento em que o operador de manutenção fizesse o download e upload do

arquivo de remessa do banco.

FIGURA 21 - Arquivo de remessa bancária CNAB (Fonte: O autor)

Mesmo com a questão técnica em desvantagem, optou-se por manter o

boleto no sistema do HSBC, pois além de sair mais barato ao usuário final, ainda

oferecia a vantagem de crédito imediato após a compensação do título, enquanto no

Pagamento Digital existia um prazo fixo de 14 dias após a compensação para saque.



54

Relatórios

Visando facilitar o acesso da Conde Curitiba aos dados armazenados no SIU

e possibilitar a sua aplicação em tempo real nas decisões estratégicas do evento,foram considerados no início do desenvolvimento a construção de alguns relatórios

administrativos, acessíveis no painel de controle, com acesso controlado por usuário

e senha. Estes relatórios não serão alvo de estudo deste trabalho, tal qual a

interface administrativa do SIE também não será. No entanto, a título de informação,

serão citados em resumo os relatórios que foram cogitados no início do

desenvolvimento:

01 - Inscrições & Pacotes: Quantidade de inscrições em cada pacote (nocaso da alimentação, separando normal e vegetariana), dividas em LOTEs, e

que demonstre também a quantidade de pagantes e não pagantes (a partir das

confirmações de pagamento). Este relatório devereria demonstrar ainda a

quantidade de camisetas de cada uma das opções selecionáveis no PASSO 1.

02 - Inscrições nos Editais: Quantidade de inscrições em cada um dos 8

editais, ao lado da quantidade de inscrições já aprovadas pelo administrador.

03 - Inscrições não concluídas: Cabeçalho com relatório quantitativo das

inscrições concluídas e não concluídas, considerando inscrição básica e

inscrição de editais. Listagem de todos os usuários que possuiam inscrições

iniciadas e não concluídas (sem todos os campos obrigatórios preenchidos).

O relatório deveria ser composto por uma seção para cada tipo de inscrição,

sendo cada seção composta por CPF, nome, e-mail e telefone. 04 - Dados quantitativos do Passo 1: Relatório com quantidade e

porcentagem de cada uma das opções de inscrição do PASSO 1, incluindo

todas as opções que sejam de questões fechadas. 05 - Ficha Básica: Opção de relatório que resgata todos os dados do

PASSO1 de um determinado usuário, a partir do seu CPF. 06 - Censo: Relatório com quantidade/porcentagem de cada uma das

variáveis do censo, acrescentado da variável ano/período atual, resgatada a

partir do PASSO 1.



55

07 - Relatórios de Editais: Relatório que resgata todos os itens de um

determinado formulário de editais, somado a alguns dados do PASSO 1 do

CPF associado. Este relatório precisaria ter saída possível em PDF e

o USUÁRIO ADMINISTRADOR teria acesso a um campo específico para

marcar a aprovação (S/N) da inscrição relativa, para que o sistema

percebesse esta variável e avisasse o usuário em sua página principal.

3.3.6 Desenvolv imento Inicial do SIU

Uma vez conhecidos os objetivos do SIU e todos os itens que deveriam ser

considerados, mas anteriormente ao detalhamento do sistema, iniciou-se o estudo

para composição da interface.

Nesta etapa preliminar o foco da discussão envolveu 3 aspectos principais:

a) Campos necessários: decisão sobre os principais campos que deveriam

compor a estrutura da interface, levando em consideração a relevância dos

mesmos, identificação básica do usuário e destaque para avisos e camposde status da inscrição;

b) Layout: agrupamento dos campos em uma ordem de leitura lógica, de

modo que facilitasse a navegação e localização de itens pelos usuários;

c) Estilo Gráfico: aplicação das cores institucionais na interface,

determinação da tipografia utilizada, desenho dos botões e demais itens da

interface.

Além da análise de similares, outra interface bastante presente na análise

preliminar foi a do Gmail, e-mail gratuito da empresa Google, reconhecida por

possuir uma interface limpa e leve. Ressalta-se aqui não só aspectos do estilo

gráfico, mas também a efetividade do feedback aos usuários e a possibilidade de

fácil retrocesso em ações efetuadas. Outro ponto considerado foi o desenvolvimento

de uma interface que apresentasse similaridade com outra já conhecida pelos

usuários. Nesse aspecto, considerou-se estratégico analisar a interface dos

principais serviços de webmail, pois a grande maioria do público-alvo já estava



56

familiarizada com eles. Segundo a Revista INFO (2010) os três serviços mais

utilizados no Brasil são: Hotmail, Gmail e Yahoo Mail.

Hotmail

Gmail

Yahoo Mail

FIGURA 22 - Comparação entre serviços de webmail (Fonte: O autor)

Comparando a interface dos três serviços notou-se que existem várias

características em comum, inclusive em suas dimensões e proporções:

a) Barra superior com logo, ajuda, informações de login e opção de logout;

b) Barra lateral esquerda com menu principal através de links textuais;

c) Espaço central com o conteúdo principal e variável;

d) Barra lateral direita para publicidade ou funcionalidade adicional.



57

A interface do Yahoo Mail se destaca por um índice relativamente alto de

janelas de alerta, consideradas irritantes por parte dos usuários, mas que ajudam a

prevenir ações não reversíveis. J á no Gmail, ao invés de janelas de alerta, são

emitidos feedbacks para cada ação realizada pelo usuário, com a opção de desfazê-

la. Estes avisos também estão posicionados no centro da tela, com fundo de texto

em amarelo, dando o devido destaque, porém sem atrapalhar uma rápida

navegação do usuário. Importante notar que o sistema também mostra, logo acima,

de maneira semelhante, quando está executando uma ação, algo importante para o

usuário não repetir um comando desnecessariamente, achando que o sistema não

respondeu. J á no Hotmail nada disso ocorre, nem alertas, nem feedback, nem opção

de reversão das ações.

Foram executadas algumas alternativas baseadas no minimalismo e botões

através de links textuais, porém os resultados não foram satisfatórios e os demais

testes foram sempre com botões gráficos. Considerou-se também a opção de dividir

a tela em 3 partes, mas o resultado também não agradou e foi constatado que não

seria necessário ter mais do que 2 seções. Uma tentativa não trabalhada foi a de

colocar as opções de login/logout, saudação e ajuda na barra superior, pois ao

contrário da interface dos webmails seria necessário um banner superior mais

carregado, seguido da barra de navegação e localização dos passos da inscrição,

que poderiam competir com essas opções, tirando o destaque merecido delas,

portanto seu agrupamento foi feito no menu lateral, como será visto a seguir.

A maior contribuição das interfaces de webmail foi a comparação do

feedback ao usuário. As janelas de alerta inoportunas do Yahoo Mail foram eleitas

para serem utilizadas em todos os momentos em que o usuário fosse realizar ações

irreversíveis, impedindo a sua navegação fluída, com o devido motivo. J á o feedback

textual do gmail foi escolhido para informar ao usuário ações realizadas com

sucesso e/ou qual seria o seu próximo passo.

Logo nas primeiras discussões chegou-se ao consenso de que além de uma

barra superior que desse acesso aos passos de inscrição, deveria existir uma barra

lateral que reunisse as informações fixas do usuário e itens que merecessem

atenção especial. Nos primeiros esboços esta barra estava posicionada no lado

direito da interface e logo após passou a figurar no lado esquerdo, por uma questão

de ordem de leitura e similaridade ao webmail, como pode ser conferido a seguir.



58

FIGURA 23 - Esboços preliminares do SIU (Fonte: O autor)

FIGURA 24 - Testes de layout do SIU (Fonte: O autor)

Para a barra lateral, além dos botões de navegação, foram alocados os

campos de saudação e identificação do usuário, dados básicos, pacotes

selecionados e status da inscrição. Para a barra superior, logo após a imagem de

topo, botões de navegação e localização do estágio da inscrição e sua respectivalegenda. Neste momento já estava decidido que os botões de navegação teriam

uma correspondência cromática que identificasse o estágio de preenchimento

daquele item (concluído, não concluído e bloqueado), além do destaque aos editais,

visto que seria a primeira vez da utilização de um sistema de inscrições unificado

junto a este público-alvo.

Foram também executados diversos testes de layout e posicionamento da

interface, antes da implementação, testando o comportamento da interface principalassociada com as diversas telas secundárias e as informações que estas conteriam.



59

Neste momento iniciou-se a redação de mensagens de feedback e status para cada

uma das situações possíveis dentro dos diversos estágios e tipos de inscrição.

No final do desenvolvimento redigiu-se um documento colaborativo que

funcionou como guia de referência e terminologia, utilizado para auxiliar na

comunicação com o programador. Não só a Comissão de TI, mas todos os membros

da Organização se envolveram nesta etapa, discutindo os campos de cada um dos

formulários de inscrição.

FIGURA 25 - Testes de interface do SIU (Fonte: O autor)

FIGURA 26 - Guia de Referência do SIU (Fonte: O autor)

O SIU foi desenvolvido entre dezembro de 2009 e início de janeiro de 2010, e

foi implementado na seqüência, utilizando HTML+PHP 5 como linguagem e o

MySQL como banco de dados. A programação HTML foi executada por Daniel

Koganas (estudante da UTFPR) e a incorporação dos códigos PHP e estruturação e

programação do Banco de Dados, por Vinícius Brand (profissional terceirizado para

o projeto).



60

A primeira parte do SIU entrou no ar no dia 29 de janeiro de 2010, às 00:00

horas, com 9 dias de atraso, quando foram registradas mais de 500 inscrições nas

primeiras 3 horas a partir do lançamento. A segunda parte do SIU foi lançada no dia

08 de fevereiro de 2010, com a abertura dos Editais para inscrição de atividades. A

partir de então, entre os meses de fevereiro e julho o sistema passou por inúmeras

versões, corrigindo bugs e implementando pequenas rotinas de melhoria usabilidade

ou novas rotinas para procedimentos auxiliares.

3.3.7 Design Estrutural e Navegação

O sistema de inscrições está baseado em uma seqüência lógica linear. De

um lado há o site do N Design e um usuário interessado no evento, de outro, existe

a inscrição efetuada com sucesso e mais um participante confirmado. No centro

deste processo está o SIU, mecanismo que irá possibilitar a ação desejada.

FIGURA 27 - O usuário, a entrada e a saída do SIU (Fonte: O autor)

Para que este processo seja concluído com sucesso é necessário que o

usuário cumpra uma série de etapas internas do SIU, onde novamente aparece uma

seqüência de passos lineares, que em resumo é composta por 4 etapas obrigatórias

e 1 opcional.



61

FIGURA 28 - Navegação simplificada do SIU (Fonte: O autor)

No entanto, ao detalhar as possibilidades de navegação nota-se que o

sistema é um pouco mais complexo. A sequência aparentemente linear passa a ser

híbrida e a permitir digressões. Além disso, as etapas incluem a navegação local,

para ações relacionadas à tarefa em si, e navegação global, através da coluna

lateral e menu superior, onde o usuário sempre tem na interface a opção de acessar

as páginas importantes do sistema.

FIGURA 29 - Seqüência híbrida, com navegação global e local do SIU (Fonte: O autor)



62

As próximas linhas tratam do entendimento de cada uma destas etapas

citadas na seqüência informacional:

Cadastro Básico: Dados essenciais para criar um usuário e entrar pela

primeira vez no SIU - CPF, nome, e-mail, senha;

Login: Controle para conexão com o SIU através de CPF e senha;

PASSO 1: Dados básicos do participante, divididos em 4 seções:

Seção A – Dados Pessoais (Nome, apelido, documentos, condição, saúde)

Seção B – Local/Contato (Endereço, telefone, redes sociais, emergência)

Seção C – Formação (Escolaridade, curso, Instituição)Seção D – Outros (Informações relativas a participação no N Design)

PASSO 2: Censo do Encontrista (Pesquisa sócio-econômica, cultural,

política e sobre os hábitos do participante, realizada pela Conde Curitiba com

intenção de colaborar com a construção participativa do evento e de criar

uma base de dados estatísticos sobre os estudantes de design que

participam de eventos.

PASSO 3: Opções de Pacote de Inscrição e Formas de Pagamento.

Além disso, existiam as opções de navegação global na coluna lateral:

Página Principal: Reunião das principais informações sobre o andamento

das inscrições, status do usuário e avisos importantes. A partir do segundo

login o usuário é sempre direcionado para esta página em primeiro lugar.

Ajuda: Tópicos de ajuda para esclarecimentos das principais dúvidas.

Fale Conosco: Opções de contato com a Comissão Organizadora.

Sair : Finaliza a sessão do usuário, fazendo logout do sistema e

redirecionando para página de login do SIU.

Através dos estudos apresentados no subitem 3.3.6 chegou-se a uma

estrutura básica (wireframe) da interface do SIU, dividindo-a em 5 partes básicas:

Cabeçalho, Menu Superior, Coluna Lateral, Coluna Principal e Rodapé, de acordo

com o que pode ser conferido na Figura 30.



63

FIGURA 30 - Cinco partes básicas do wireframe do SIU (Fonte: O autor)

Seguindo com o detalhamento a partir do wireframe algumas destas partes

podem ser destrinchadas para melhor refinamento, com a apresentação dos seus

itens, já se aproximando do desenvolvimento do layout da interface final:

FIGURA 31 - Detalhamento do design estrutural do SIU (Fonte: O autor)



64

Segue-se com a descrição de cada um dos itens apresentados no design

estrutural:

CABEÇALHO: Banner do Sistema de Inscrições do N2010.

MENU SUPERIOR: Legenda com código cromático para status das etapas

de inscrição e botões das etapas obrigatórias (Passo 1, 2 e 3) e etapa

opcional (Editais), com seus respectivos rótulos.

COLUNA LATERAL: Opções de navegação global e principais

informações sobre o usuário e sua inscrição.

Saudação Apelido: No formato “Olá #Apelido!” cumprimenta o usuário

através do resgate do seu apelido no Banco de Dados (ou primeiro nome, no

caso de não conclusão do Passo 1).

Página Principal: Botão de acesso para Página Principal.

Ajuda: Botão de acesso para página de Ajuda.

Dados Pessoais: Box com os principais dados de identificação do usuário(nome completo e e-mail) e opção para ver os demais (link com o Passo 1).

Pacotes Selecionados: Box com a relação dos pacotes selecionados pelo

usuário no Passo 3, ou “Você não selecionou nenhum pacote”.

Status da Inscrição: Box com a informação do status da inscrição do usuário,

com mensagens variáveis de acordo com a sua progressão da inscrição.

Fale Conosco: Botão de acesso para página de Fale Conosco.Sair: Botão para finalizar a sessão e fazer o logout do sistema.

COLUNA PRINCIPAL: Local onde era carregado o conteúdo de qualquer

página interna do SIU.

RODAPÉ: Espaço para logos dos realizadores e parceiros de

desenvolvimento do sistema.



65

3.3.8 Detalhamento da Interface

Em seqüência ao desenvolvimento do SIU, a partir do wireframe, foi

detalhada a interface, com a criação de um layout que considerou aspectos daidentidade visual do N2010 e objetivos associados ao Design da Informação.

O menu superior, além de possibilitar a navegação do usuário entre as etapas

de inscrição, utilizou-se como elemento de orientação, fortalecendo a mensagem de

procedimento de inscrição seqüencial e linear.

FIGURA 32 – Rascunho do Layout do Menu Superior (Fonte: O autor)

O detalhe da Figura 32 demonstra a inflexão dos blocos das etapas da

inscrição, simbolizando o seu sequenciamento, assim como a separação da etapados editais, que era opcional. Abaixo dos blocos aparece o rótulo da etapa,

facilitando a utilização do usuário. Outro elemento adicionado foi a cor, diferenciando

etapas completas e incompletas, assim como as que não podem ser acessadas, e

ainda reforçando a separação dos editais dos demais botões.

FIGURA 33 – Layout Finalizado do Menu Superior (Fonte: O autor)

FIGURA 34 – Legenda do Menu Superior (Fonte: O autor)



66

Visando obter uma padronização de botões clicáveis por similaridade de

formato os demais seguiram o estilo. Foi pensado também em uma diferenciação de

página ativa ou inativa através da simulação de volume e sombreamento. Na versão

final implementada, este recurso não foi seguido pelo programador, no entanto foi

previsto e desenvolvido na etapa de criação, conforme demonstra a Figura 35.

Inativo: Ativo:

FIGURA 35 – Diferenciação entre botões ativos e inativos (Fonte: O autor)

Para todos os itens da interface foram utilizadas cores próximas as da paleta

da identidade visual do evento, notadamente os tons de cinza, bordô e verde.

Apenas para os editais, novamente em destaque, foram utilizados tons de azul.

FIGURA 36 – Paleta de cores da interface do SIU (Fonte: O autor)



67

O banner do cabeçalho foi desenvolvido a partir de elementos texturizados da

identidade visual do N2010 presentes no site e itens do material gráfico.

FIGURA 37 – Padrão gráfico do site do N2010 (Fonte: O autor)

FIGURA 38 – Banner do N2010 para o cabeçalho do SIU (Fonte: O autor)

A família tipográfica principal indicada no arquivo CSS para todos os estilos

de texto é a Tahoma, em sua versão normal e versão bold. O corpo do texto varia

entre o tamanho 10 e tamanho 16.

FIGURA 39 – Família tipográfica utilizada (Fonte: O autor)

A última versão do rascunho da interface em papel ficou bastante próxima da

versão final, como pode ser conferido na Figura 40 e Figura 41.



68

FIGURA 40 – Rascunho final da interface do SIU (Fonte: O autor)

FIGURA 41 – Interface final do SIU (Fonte: O autor)



69

3.3.9 Detalhamento dos Formulários

Neste capítulo serão demonstradas as tabelas de dados de todos os

formulários do SIU, seus botões de confirmação e principais links.O desenvolvimento das questões do formulário foi um assunto

exaustivamente discutido e revisado dentro da Conde Curitiba. Devido a extensão

dos formulários foi bastante utilizado o fator lúdico e cômico para distrair o usuário

em relação ao tempo despedido na sua inscrição. Especialmente nas questões do

PASSO 2 – Censo pode ser observado isso, até pelo fato do Censo do Encontrista

ser uma proposta inovadora do N2010, fazendo com que até mesmo os veteranos

de evento ficassem surpresos com a extensão do formulário.Para o correto entendimento das tabelas de dados é necessário observar a

legenda da Tabela 05.

TABELA 05 - Legenda para das tabelas de dados dos formulários

Item / Símbolo Descrição

No Número do campo no formulário, quando existir.

NOME DO CAMPOCampo completo ou abreviado da maneira como é exibido ao usuário natela (não corresponde a nomenclatura que o campo recebe no banco de

dados) TIPO Definição do tipo de campo para efeitos de visualização e armazenamento

TAM. Quantos caracteres são armazenáveis nesta variável

OBSERVAÇÕES Observações importantes sobre verificação, funcionamento,armazenamento.

* Preenchimento obrigatório do campo

** Preenchimento obrigatório e não permição de edição posterior ao primeirosalvamento

*c Preenchimento obrigatório condicional ao resultado de questão anterior

{i} Campo Invisível – existente apenas no armazenamento da tabela

correspondente no banco de dados

{b} Campo Bloqueado – Aparece na tela, porém não permite a edição dousuário

Fonte: O autor.

TABELA 06 - Login

NOME DO CAMPO TIPO TAM. OBSERVAÇÕES

** CPF (somente números) Txt Simples 11 Verificação formato

** Senha Txt Password 4-15 Verificação formato

[botão] OK!

[link] Novo cadastro[link] Esqueci minha senha

Fonte: O autor.



70

TABELA 07 - Esqueci minha senha



[botão] Recuperar senha[link] LoginFonte: O autor.

TABELA 08 - Cadastro básico



** Nome Txt Simples 60

** Sobrenome Txt Simples 60

** E-mail Txt Simples 255 Verificação formato* Confirme se e-mail Txt Simples 255 Campo de checagem

** Senha Txt Password 4-15 Verificação formato

* Confirme sua senha Txt Password 4-15 Campo de checagem

[botão] OK!

[link] J á sou cadastradoFonte: O autor.

TABELA 09 - PASSO 1: Dados básicos – Seção A (Dados Pessoais)

No NOME DO CAMPO TIPO TAM OBSERVAÇÕES

{i} ID Txt Simples 20 Chave primária cadastro(auto incrementável)

{b} 1 CPF (somente números) Txt Simples 11 Verificação formato

{b} 2 Nome Txt Simples 60

{b} 3 Sobrenome Txt Simples 60

* 4 Apelido Txt Simples 60

* 5 Gênero Menu Lista 1 Escolha/Fem./Masc.

* 6 Data de Nascimento Menu Lista Date Campo Formato Data

* 7 Número do RG Txt Simples 20* 8 Expedição RG / Data Menu Lista Date Campo Formato Data

* 8 Expedição RG / Órgão Expedidor Txt Simples 12

* 8 Expedição RG / Estado Emitido Menu Lista 20 Lista com todos osestados

* 9 Profissão/Ocupação Txt Simples 60

* 10 Portador Necessidades Especiais Menu Lista 4SelecioneSim (aparece no 10.1)Não (pula para no 11)

*c 10.1 Qual(is) Txt Simples 255

11 Plano de Saúde Txt Simples 60* 12 Tipo Sanguíneo Menu Lista 5 Lista Tipos/Fator RH



71


13 Alergias Txt Simples 255

* 14 Toma medicação controlada? Menu Lista 4SelecioneSim (aparece no 14.1)

Não (pula para no 15)*c 14.1 Qual(is) Txt Simples 255

* 15 Em caso de emergência / Nome Txt Simples 60

* 15 Em caso de emergência / Telefone (com DDD) Txt Simples 20 Máscara visualização /

somente númerosFonte: O autor.

TABELA 10 - PASSO 1: Dados básicos – Seção B (Local/Contato)


{i} ID Txt Simples 20 Chave primária docadastro

* 1 CEP (somente números) Txt Simples 8 somente números

* 2 Logradouro (Rua, avenida, ...) Txt Simples 255

* 3 Número Txt Simples 8 somente números

4 Complemento Txt Simples 255

* 5 Bairro Txt Simples 255

* 6 Cidade Txt Simples 70

* 7 Estado Menu Lista 20 Lista com Estados +Forado Brasil

* 8 País Menu Lista 20 Lista com Países

9 Telefone (com DDD) Txt Simples 20 Máscara visualização /somente números

10 Celular (com DDD) Txt Simples 20 Máscara visualização /somente números

{b} 11 E-mail Txt Simples 255

12 MSN Txt Simples 255

13 Google Talk (seu gmail) Txt Simples 255

14 Orkut Txt Simples 255

15 Twitter Txt Simples 25516 Website/blog Txt Simples 255

Fonte: O autor.



72

TABELA 11 - PASSO 1: Dados básicos – Seção C (Formação)

No NOME DO CAMPO TIPO TAM. OBSERVAÇÕES

{i} ID Txt Simples 20 Chave primária do cadastro

* 1 Escolaridade Menu Lista 20

(padrão em branco)Ens. Fundamental (pula p/ no 10)Ens. Médio (pula p/ no 10)Ens. Técnico (pula p/ no 10)Superior Andamento (no 2 a no

6)Superior Incompleto (no 2 a no

6)Superior Completo (no 2 a no 7)Pós-Graduação (no 2 a no 9)

*c 2 Instituição de Ens. Superior Txt Simples 255

*c 3 Sigla Txt Simples 15*c 4 Curso Txt Simples 255

*c 5 Habilitação Menu Lista 20

(padrão em branco)GráficoProdutoModaWebInterioresDigitalAnimaçãoGamesBacharelado em DesignOutrasNão faço Design

*c 6 Oferta de Disciplinas Menu Lista 1SelecioneAnual (aparece no 6.1)Semestral (aparece no 6.2)

*c 6.1 Ano que está matriculado Menu Lista 20(padrão em branco) / 1º Ano /2º Ano / 3º Ano / 4º Ano / 5ºAno

*c 6.2 Semestre que estámatriculado Menu Lista 20

(padrão em branco) /1º Semestre / 2º Semestre /3º Semestre / 4º Semestre /5º Semestre / 6º Semestre /

7º Semestre / 8º Semestre /9º Semestre / 10º Semestre

*c 7 Ano de conclusão Txt Simples 4

*c 8 Instituição de Pós-graduação Txt Simples 255

*c 9 Linha de Pesquisa Txt Simples 255

*c 10Instituição de Ensino(Fundamental, Médio e Técnico)

Txt Simples 255

Fonte: O autor.



73

TABELA 12 - PASSO 1: Dados básicos – Seção D (Outros)


{i} ID Txt Simples 20 Chave primária do cadastro

** 1 Tamanho da Camiseta Menu Lista 10 Selecione / Fem P / Fem M /Fem G / Fem GG / Masc P /Masc M / Masc G / Masc GG

2 Delegação Txt Simples 255Campo de ajuda: Delegação éum grupo de pessoas que vem juntas ao evento...

* 3 Meio de Transporte paraCuritiba Menu Lista 20

Selecione / Avião / Ônibus /Carro / J á sou de Curitiba /Outra Opção

* 4 Permanência na Cidade alémdo evento Menu Lista 4 Selecione / Sim / Não

* 5 Pretende fazer turismo Menu Lista 4 Selecione / Sim / Não

* 6 Como tomou conhecimento doN Design Imersão CheckBox

Cartaz / Orkut / Twitter / Blogdo N / Outros sites / Chefe dedelegação / Através deconhecidos / Apresentação daequipe / 00N Agentes daConde / Revista / Outroseventos / Em sala de aula /Centros ou DiretóriosAcadêmicos / Outros

* 7 Este será o seu 1º N Design? Menu Lista 4 Selecione / Sim / Não

Visualização do Termo de Responsabilidade

* Li e concordo com o Termo deResponsabilidade

CampoBooleano 1 Obrigatório marcar o campo

para prosseguir.

[link] Versão do Termo de Responsabilidade em PDF para visualização

[botão] SALVAR

[botão] ENVIARFonte: O autor.

As seções A, B, C e D foram separadas em grupos de afinidade acima tal qual

estão separadas na visualização ao usuário, porém todas em uma mesma página,correspondente ao PASSO 1, onde todos os campos são salvos somente 1 vez, no

botão correspondente no final da página.

TABELA 13 - PASSO 2: Censo do encontrista


{i} ID Txt Simples 20 Chave primária da tabela censo(auto incrementável)

{i} IDUSUARIO Txt Simples 20 Chave primária da tabela usuario

* 1 É estudante do Ens.Superior? Menu Lista 4

SelecioneSim (aparece no 2 a no 7)Não (pula p/ no 8)



74


*c 2Quando entrou na suainstituição de EnsinoSuperior? / Semestre

Menu Lista 20Selecione1º Semestre2º Semestre

*c 2Quando entrou na suainstituição de EnsinoSuperior? / Ano

Menu Lista 20Selecione / 2000 / 2001 / 2002 /2003 / 2004 / 2005 / 2006 /2007 / 2008 / 2009 / 2010

*c 3 Qual o ano de previsãode sua formação? Menu Lista 20

Selecione / 2010 / 2011 / 2012 /2013 / 2014 / 2015 / 2016 /2017 / 2018

*c 4 Estado onde estuda Menu Lista 20 Lista com Estados +Fora do Brasil

*c 5 Região RadioBox 20 Capital / Metropolitana / Interior

*c 6 Qual o regime dos seusestudos? RadioBox 30 Público / Privado / Privado PROUNI

/ Privado Bolsista

*c 7 No momento você: (de 1a 5, sendo 1 o mínimo e5 o máximo)

Escala deOposiçãoSemântica(1 a 5)

20

(1) Sou turista no curso.(5) Faço todos os trabalhos, estudopara provas e participo deatividades de pesquisa e extensão.

* 8 Renda Familiar RadioBox 50

Até 3 salários mínimos3 a 5 salários mínimos5 a 8 salários mínimos8 a 10 salários mínimos10 salários mínimos ou mais

* 9Na sua trajetóriaacadêmica, você jáfoi/fez:

CheckBox 20

Representante de Turma;Representante Discente do Curso,ou outras instâncias superiores;

Centro ou Diretório Acadêmico;Diretório Central dos Estudantes -DCE;

Empresa J únior;Comissão de Formatura;Bolsista, Monitoria ouPermanência;

Iniciação Científica;Mobilidade Acadêmica;Intercâmbio;Morador de Casa do Estudante;Organizador de evento estudantil;Nenhum dos anteriores.

* 10Quantas vezes vocêparticipou dos eventos aseguir:

- - -

* 10.1N Design (EncontroNacional dos Estudantesde Design)

Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.2R Design (EncontroRegional dos Estudantesde Design)


* 10.3 Semanas Acadêmicas Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.4 Encontros Locais Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.5 Encontros Municipais Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais* 10.6 ExpoDesign Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais



75


* 10.7 Megafônicas Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.8 Bienais de Design Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.9 Congressos Científicos Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 10.10

CONE Design (ConselhoNacional dos Estudantesde Design)


* 10.11 Outros Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

* 11 Você desenvolveualguma atividade CheckBox -

Não, só fui como encontrista /participante;

Monitor;Oficineiro;Convidado;Palestrante;Sepa (Seminários de ProduçãoAcadêmica) / Apresentação detrabalhos Acadêmicos;

OrganizadorRepresentante do CONE Design;Gestor de Balaio / Grupo deDiscussão.

Outros

* 12 O que mais te interessano N CheckBox -

Tudo, sou viciado em eventos;Palestras, gosto de ouvir alguémfalando;

Debates e mesas redondas, adorouma boa briga;

Festas, só vou pra curtir;Oficinas, adoro colocar a mão namassa.

Reuniões do CONE Design, querofazer a diferença;

Atividades espontâneas, viva ainteração;

Bazar, sou muito consumista;Turismo, só vou para passear;Grupos de discussão, adoro umbom bate-papo;

Outros.

* 13

Qual o seu grau departicipação noseventos?* (de 1 a 5,sendo 1 o mínimo e 5 omáximo)


20

(1) Mínimo, só faço minha inscrição.(5) Insano, participo de 3 atividadesao mesmo tempo enquanto ajudo acomissão organizadora.

* 14Quanto a estrutura doevento, o que é osuficiente para você?


20(1) Um pedaço de chão para dormire uma bica pra tomar banho.(5) Desencana, vou pra um hotel.

* 15Qual seu grau deempolgação para oevento?

Escala deOposiçãoSemântica

(1 a 5)

20

(1) Só vou porque preciso de horasde atividade complementar.(5) Por mim começava agora

mesmo!



76


* 16Quanto você sepreocupa com asustentabilidade?


(1 a 5)

20(1) Sustenta o que?(5) Eu sou o Capitão Planeta (VAIPLANETA!)

* 17

Quanto você sepreocupa com oconteúdo/projeto doevento do qual você vaiparticipar?


20

(1) Projeto? Que projeto? Temprojeto?(5) Eu li o projeto na íntegra, discuticom os organizadores, revi todoreferencial teórico e ainda divulgueino meu curso.

* 18 Quanto aos seushorários:


20(1) Nem megafone me acorda!(5) Acordo na hora certa sem usardespertador.

* 19 Quanto a suaalimentação:

Escala de

OposiçãoSemântica(1 a 5)

20

(1) Pão com vina* me sustenta

(5) Faço 6 refeições por dia.*Vina é como os habitantes deCuritiba chamam a Salsicha.

* 20 Quanto ao tipo dealimentação:


20

(1) Sou vegetariano e não abro mãodisso!(5) Como o que vier pela frente, depreferência ainda sangrando.

* 21 Sobre sua opção sexual:


20 (1) Hetero(5) Homo

* 22 Sobre cigarro:


20 (1) Não Fumo.(5) Fumo 1 a 2 maços por dia

* 23 Com relação aotrabalho:

Menu Lista 40

Selecione; (opção padrão) Tenho emprego com carteiraassinada; Tenho emprego sem carteiraassinada;Sou Freelancer;Faço Estágio;Faço Trabalho Voluntário;Não trabalho. (pula p/ no 25)

*c 24 Responda se é por: Menu Lista 40

Selecione; (opção padrão)Experiência;Necessidade;Opção;Obrigatoriedade (ex. EstágioSupervisionado)

* 25

Você conhece a PNU?(linkhttp://pnu.wikispaces.com)


20(1) Aquele das Nações Unidas?(5) Sempre acompanho no wiki daPNU.

* 26

Você participa da lista doCONE Design?(linkhttp://conedesign.org.br)


20

(1) Que lista?

(5) Eu leio e respondo todos os e-mails.



77


* 27 Áreas de interesse:*(marque 5 alternativas) CheckBox -

ModaCinema e VídeoFilosofia

MobiliárioJ óiasAnimação 2DAnimação 3DEmpreendedorismoTeatroSemióticaDesign da InformaçãoFood DesignDesign de InterioresMúsica/DançaSustentabilidadeTecnologia/materiais

Movimento EstudantilIlustraçãoHQTipografiaGênero (Masc/Fem)EditorialEstampariaCriatividadeInovaçãoDesign de brinquedosArtesanatoDesign VernacularDesign de Produtos

Intervenção UrbanaHistória/Teoria do DesignBrandingAntropologiaArquiteturaDesign EmocionalDesign SensorialCerâmicaEmbalagensBiônicaCorOrganização de eventosVitrine

PerfumeMalabares/circoPsicologiaPesquisaFantasiaArtes PlásticasDesign tipo exportação

[botão] SALVAR


O formulário de Censo do Encontrista não poderia ter nenhum campo alterado

uma vez que fosse enviado, nem mesmo poderia ser visualizado pelo usuário. Neste



78

formulário aparecem várias escalas de oposição semântica, visando a coleta de

dados de enquadramento intermediário entre valores opostos para uma determinada

questão. Todas estas escalas dentro do SIU são numeradas de (1) a (5).

FIGURA 42 - Exemplo de escala de oposição semântica (Fonte: O autor)

TABELA 14 - PASSO 3: Seleção de pacotes


{i} ID Txt Simples 20

Chave primária da tabela pacote

(auto incrementável)

{i} IDUSUARIO Txt Simples 20 Chave primária da tabelausuario

{b} Inscrição Básica (R$XX) - - (veja explicação abaixo)

** Alojamento (R$XX) CampoBooleano 4

** Alimentação Não-Vegetariana(R$XX)

CampoBooleano 4

** Alimentação Vegetariana(R$XX)

CampoBooleano 4

Através de uma rotina em javascript é feito um controlepara permitir a seleção deapenas um dos pacotes dealimentação.

** Festas (R$XX) CampoBooleano 4

*Estou ciente de que nãopoderei alterar a seleção depacotes no futuro.

CampoBooleano - Obrigatório marcar o campo

para prosseguir.

[caixa de texto estático] Visualização das Informações sobre lotes, isenções, pacotes e pagamento.

*

Li e concordo com asInformações sobre lotes,isenções, pacotes epagamento.

CampoBooleano - Obrigatório marcar o campo

para prosseguir.

[link] Versão do Termo em PDF para visualização (link externo)


O Pacote de Inscrição Básica era obrigatório para qualquer participante que

concluísse a inscrição. Logo, o campo apenas aparecia na tela, já pré-selecionado e

bloqueado, sem possibilidade de alterar a seleção. Na tabela do banco de dados não

existe um campo “inscricaobasica”, pois qualquer usuário que tenha salvado a

seleção de pacotes terá necessariamente visualizado e concordado com a seleção evalores relacionados.



79

Os valores em tela dependiam dos valores salvos no sistema no sistema para

cada pacote, do lote vigente e também do desconto de isenção parcial ou total

associado ao usuário.

TABELA 15 - PASSO 3: Forma de pagamento

NOME DO CAMPO TIPO TAM OBSERVAÇÕES

{i} ID Txt Simples 20 Chave primária da tabelapagamento (auto incrementável)


{b} Inscrição Básica (R$XX) - -

{b} Alojamento (R$XX) - -

{b}

Alimentação Não-Vegetariana

OU Vegetariana (R$XX) - -{b} Festas (R$XX) - -

Apenas exibição paraconfirmação da seleção depacotes salva na tabela pacotese seus respectivos valoresvigentes na ocasião da emissãode pagamento.

{b} Valor Decimal 11,2

Valor do Pagamento Líquido(descontando taxas, que eramsomadas apenas paravisualização do usuário, mas nãoarmazenadas)

{i} Lote Txt Simples 20Informação numérica relativa aolote vigente quando emitido opagamento

** Forma de Pagamento Txt Simples 1

V = Boleto HSBC

P =Pagamento DigitalI =Isenção Total

{i} Data de Emissão Date Date

{i} Ativo CampoBooleano 4 Padrão: “1”

{i} Pago CampoBooleano 4 Padrão: “0”

[botão] GERAR BOLETO (armazena “V” na Forma de Pagamento)

[botão] PAGAR PARCELADO (armazena “P” na Forma de Pagamento)

[link] Faça uma simulação dos valores para pagamento parcelado (link externo)

*c [botão] CONFIRMAR INSCRIÇÃO (armazena “I” naForma de Pagamento)

Opção oculta que aparece nolugar dos 2 botões de pagamentoapenas quando o usuário temdireito a isenção total

Fonte: O autor.

Inicialmente os formulários de pacotes e pagamento estavam unidos em uma

mesma página. Durante a implementação decidiu-se que as tabelas ficaram mais

organizadas caso fossem etapas em separado. Por isso os formulários eram

carregados em páginas separadas, para fazer um pagamento era necessário antes

ter feito a seleção dos pacotes desejados.



80

Observações complementares

O campo “Ativo” era setado por padrão em “1”, porém depois do prazo de

pagamento (5 dias) ou havendo resposta negativa sobre o pagamento de um título,este campo era setado em “0”. Desta forma, o usuário teria que emitir um novo

pagamento ao acessar o sistema, gerando uma nova entrada no banco de dados,

ficando a anterior armazenada por motivos de segurança. No caso de pagamentos

confirmados o usuário passava a ter o campo “Pago” setado em “1”, sendo este

registro consultado para gerar uma mensagem de status positiva em relação ao

pagamento, diretamente na composição de sua interface. Abaixo, observa-se na

Figura 43 um exemplo de usuário que fez várias emissões de pagamento, passando

pelos 3 LOTES, com diferentes valores de pagamento emitido através de boleto, até

finalmente pagar um título através de pagamento parcelado e confirmar a sua

inscrição.

FIGURA 43 - Exemplo de usuário com múltiplos pagamentos emitidos (Fonte: O autor)

TABELA 16 - EDITAIS: Campos padrão e invisíveis dos editais


{i} ID Txt Simples 20 Chave primária da tabela editais(auto incrementável)


{i} Data de Inscrição da Atividade datetime - Armazena Data e Hora

{i} Data Última Atualização datetime - Armazena Data e Hora

{i} Revisor de Avaliação Txt Simples 40 Nome do Revisor que avaliou aatividade

{i} Status de Avaliação Menu Lista 255

Novo (padrão)AprovadoReprovadoNão IndicadoCancelado

{i} Enviado CampoBooleano 1 “0” Não enviado“1” Enviado (padrão)



81


{i} Tipo de Edital Txt Simples 255

Diferencia tipo de editalsubmetido por um código.Mergulhos: “111”

Quebrando o Gelo: “112”SEPA: “12”Mostra de Vídeos: “13”Representante do Cone: “2”Monitor: “4”Chefe de Delegação: “3”Bazar: “6”

Fonte: O autor.

Todos os Editais armazenavam seus dados em uma mesma tabela do banco

de dados. No entanto, ao usuário utilizador, os formulários apareciam de modo

totalmente distinto. Cada submissão de edital ficaria armazenada com uma ID única

na tabela editais, sendo esta associada ao IDUSUARIO.

TABELA 17 - EDITAIS: Inscrição de atividade Mergulho


{i} CAMPOS PADRÃO E INVISÍVEIS DOS EDITAIS

{b} Nome do Instrutor Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário

(apenas para visualização)** Currículo breve do Instrutor Txt Longo 512

** A atividade terá mais de uminstrutor

CampoBooleano

1 “0” – Pula 3 campos“1”- Aparecem 3 prox. Campos

*c J ustifique a necessidade de umsegundo instrutor Txt Longo 2048

*c Nome do Segundo Instrutor Txt Simples -

*c Currículo breve do SegundoInstrutor Txt Longo 512

** Título da Atividade Txt Simples 100

** Informações Específicas Txt Longo 2048(descrição completa utilizadapara seleção do Mergulho,explicando conceito, metodologiae funcionamento da atividade)

** Resumo (sinopse) Txt Longo 256 (para o guia do encontrista e site)

Resultado (pré-requisito para aatividade ser um mergulho) Txt Longo 512

(descreva o resultado daatividade, seja ele através detexto, de um mural, de objetosconstruídos, etc.)

** Cronograma Txt Longo 1024 (defina o cronograma daatividade em tópicos)

** Mínimo de mergulhadores Txt Simples 20 (número mínimo de participantes)

** Máximo de mergulhadores Txt Simples 20 (número máximo departicipantes)



82


** Tempo Necessário Menu Lista 2551h30 (mergulho raso)3h (mergulho médio)5h (mergulho profundo)

Classificação da atividadeEscala deOposiçãoSemântica(1 a 5)

-(escolher e preencher até 4escalas que melhor definam suaatividade, classificando seumergulho)

**Prático (1) (_) (_) (_) (5) Teórico

Design Gráfico (1) (_) (_) (_) (5) Design de ProdutosProfissional (1) (_) (_) (_) (5) Acadêmico

Trabalho Manual (1) (_) (_) (_) (5) Trabalho DigitalIndividual (1) (_) (_) (_) (5) ColetivoSubjetivo (1) (_) (_) (_) (5) ObjetivoLúdico (1) (_) (_) (_) (5) Realista

Design (1) (_) (_) (_) (5) Outras áreas

** Material Necessário Txt Longo 2048(apresente a quantidade e a justificativa de uso de cadamaterial)

**Disponibilidade para ministrar aatividade duas vezes durante oevento?

CampoBooleano 1

Este campo esta relacionadocom a votação para repetição deatividades do SIE.

** A atividade já foi ministradaantes? Onde e Quando? Txt Simples 128

Link do anexo: Formato .pdf Txt Simples 128

Opção para envio de materiaiscomplementares a proposta deatividade, conforme disposto noedital.

** Por que sua atividade deve estarno NDesign Imersão? Txt Longo 512

Li e compreendi o edital deMergulhos [link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downloads/editais/n2010_mergulho.pdf

[botão] CONFIRMARFonte: O autor.

TABELA 18 - EDITAIS: Inscrição de atividade Quebrando o Gelo



{b} Nome do Instrutor Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

** Currículo breve do Instrutor Txt Longo 512

** A atividade terá mais de uminstrutor

CampoBooleano 1 “0” – Pula 3 campos

“1”- Aparecem 3 prox. Campos

*c J ustifique a necessidade de umsegundo instrutor Txt Longo 2048

*c Nome do Segundo Instrutor Txt Simples -



83


*c Currículo breve do SegundoInstrutor Txt Longo 512

** Título da Atividade Txt Simples 100

** Informações Específicas Txt Longo 2048

(descrição completa utilizadapara seleção do Mergulho,explicando conceito, metodologiae funcionamento da atividade)


**Onde prefere Quebrar o Gelo? Épossível ser em ambienteexterno? Qual?

Txt Longo 256(diga se é essencial que o lugarseja fechado ou aberto, comgrama ou mata fechada, etc.)

** Mínimo de mergulhadores Txt Simples 20 (número mínimo de participantes)

** Máximo de mergulhadores Txt Simples 20 (número máximo departicipantes)

** Material Necessário Txt Longo 2048(apresente a quantidade e a justificativa de uso de cadamaterial)




** Por que sua atividade deve estarno NDesign Imersão? Txt Longo 512

Li e compreendi o edital doQuebrando o Gelo [link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downloads/editais/n2010_quebrandogelo.pdf


TABELA 19 - EDITAIS: Inscrição de atividade SEPA



{b} Nome Responsável Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

** Currículo breve do Instrutor Txt Longo 512

** Título Txt Simples 100

Autores Txt Simples 128

** Orientador Txt Simples 128

** Caráter Menu Lista 255 TCC (pula 1 questão)Iniciação Científica (pula 1 ques.)Outro (aparece questão abaixo)

*c Qual? Txt Simples 50



84


** Ano de Conclusão Txt Simples 4


(descrição completa utilizadapara seleção do Mergulho,

explicando conceito, metodologiae funcionamento da atividade)


** Palavras-chave (até 3) Txt Simples 100

** Apresentação Menu Lista 255

Categorias distintas para seleçãodos SEPAS:Multimídia;Pôster.




Li e compreendi o edital deSeminário de ProduçãoAcadêmica (SEPA) [link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downloads/editais/n2010_sepa.pdf


TABELA 20 - EDITAIS: Inscrição de atividade Mostra de VídeoNOME DO CAMPO TIPO TAM OBSERVAÇÕES


{b} Nome Responsável Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

** Título Txt Simples 100

Responsável pelo vídeo Txt Simples 255


(descrição completa utilizadapara seleção do Mergulho,

explicando conceito, metodologiae funcionamento da atividade)


** Categoria Menu Lista 255

Documentário (padrão)AnimaçãoVídeo ClipeFicçãoExperimentalInstitucional

Técnica Utilizada (para odesenvolvimento do filme) Txt Simples 255

** Tempo de Duração Menu Lista Time Formato MM:SS



85


** Link para o vídeo Txt Simples 128

Ao invés de receber os arquivosno momento do envio do editaloptou-se por apenas receber um

link para visualização, sendo osarquivos solicitados somente aosaprovados.

**O vídeo já foi exibido ou recebeualguma premiação? Onde eQuando?

Txt Simples 128

Li e compreendi o edital deMostra de Vídeos [link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downloads/editais/n2010_mostradevideos.pdf

[botão] CONFIRMAR

Fonte: O autor.

TABELA 21 - EDITAIS: Inscrição de Representante do Cone Design



{b} Nome Representante Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

** Entidade de Base Txt Simples 60 (no caso de indicação através de

Centro ou Diretório Acadêmico)** J á foi Representante em outra

edição do Cone Design?CampoBooleano 1 “0” – Padrão

“1” – Aparece campo abaixo.

*c Caso sim, onde e quando? Txt Simples 128



Li e compreendi o edital deRepresentante do Cone Design[link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downlo

ads/editais/n2010_representantecone.pdf


TABELA 22 - EDITAIS: Inscrição de Monitor



{b} Candidado à monitoria Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário

(apenas para visualização)



86


** Disposição Física (quanto àforça)


(1 a 5)

20 (1) Fraco(5) Forte

** Disposição Física (quanto àagilidade)


20 (1) Lento(5) Ágil

** Pratica esportes? CheckBox -

BasqueteCiclismoFutebolGinásticaMusculaçãoNataçãoTênis

VôleiOutroNão, sou sedentário

Qual outro(s) esporte(s)? Txt Simples 60

** Altura


20 (1) Baixo(5) Álto

** Habilidades Específicas CheckBox -

Instalação de equipamentoseletrônicos

Boa comunicação pessoalUso de ferramentas (pá,

martelo, chave de fenda, serra,etc)Famiiaridade com o ConeDesign

Outra

Que outra(s) habilidade(s)específica(s) Txt Simples 100

Fala outro(s) idioma(s) além doportuguês Txt Simples 60

(Explique com detalhes seu graude proficiência no(s) idioma(s)citados.)

Quantas vezes você participoudos eventos a seguir: - - -

N Design Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

R Design Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Semanas Acadêmicas Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Encontros Estaduais/Locais Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Encontros Municipais Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

ExpoDesign Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Megafônicas Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Bienais de Design Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

Congressos Científicos Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

CONE Design Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais

**

Outros Menu Lista 20 0 / 1 / 2 / 3 / 4 / 5 ou mais



87


** Você desenvolveu algumaatividade nestes eventos? CheckBox -

Não, só fui como encontrista /participante;

Monitor;

Oficineiro;Convidado;Palestrante;Sepa (Seminários de ProduçãoAcadêmica) / Apresentação detrabalhos Acadêmicos;

OrganizadorRepresentante do CONEDesign;

Gestor de Balaio / Grupo deDiscussão.

Outros

**Pretende desempenhar algumaoutra atividade no N2010, alémde Monitoria?

CheckBox -

Representante do CONEMergulhadorQuebrador de GeloBazarDebate de Mesa RedondaApresentação de TrabalhosAcadêmicos

Mostra de VídeosNão, apenas Monitoria

** Na sua universidade, você jáparticipou de: CheckBox 20

Representante de Turma;Representante Discente doCurso, ou outras instânciassuperiores;

Centro ou Diretório Acadêmico;Diretório Central dosEstudantes - DCE;

Empresa J únior;Comissão de Formatura;Bolsista, Monitoria ouPermanência;

Iniciação Científica;Mobilidade Acadêmica;Intercâmbio;Morador de Casa do Estudante;Organizador de eventoestudantil;

Nenhum dos anteriores.** Tem disponibilidade de chegar

antes em Curitiba?CampoBooleano 1 “0” – Padrão

“1”

** Pretende ficar no alojamento doevento?

CampoBooleano 1 “0” – Padrão

“1”

** Por que quer ser monitor? Txt Longo 512

**Existe alguma atividadeespecífica de Monitor que vocêgostaria de executar?

Txt Longo 256

** Em qual dos horários você tem

preferência pelo seu turno livre?

Menu Lista 255Manhã – padrão Tarde

Noite



88


** Li e compreendi o edital deMonitoria [link]

CampoBooleano 1


ads/editais/n2010_monitoria.pdf [botão] CONFIRMAR

Fonte: O autor.

TABELA 23 - EDITAIS: Inscrição de Chefe de Delegação



{b} Nome do Chefe de Delegação Txt Simples -Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

* Nome da Delegação Txt Simples 100

* Estimativa de pessoas nadelegação (número) Txt Simples 20

* Cidade de Origem Txt Simples 100

Estado de Origem Menu Lista 20 Lista com todos os estados +Fora do País

* Data da viagem para Curitiba Menu Lista Date

* Data de volta Menu Lista Date

* Transporte Menu Lista -Avião (padrão)ÔnibusVan

* J á foi Chefe de Delegação emoutra edição do NDesign?

CampoBooleano 1 “0” – Padrão

“1”

*c Caso sim, onde e quando Txt Longo 256

Preenchimento de pelo menos 40 membros com os dados abaixo para cada 1 dos membros:

[link] Adicionar novo membro

CPF Txt Simples 11

Com validação, além de checarse é CPF válido verifica einforma na listagem se o usuárioexiste, se está pendente ou se já

está com pagamento confirmado.Nome Txt Simples Apenas para referência

[link] adicionar à delegação

*

[link] remover membro

** Li e compreendi o edital deChefe de Delegação [link]

CampoBooleano 1

Obrigatório ser marcado paraconfirmar envio do formulário.http://ndesign.org.br/2010/downloads/editais/n2010_chefedelegacao.pdf




89

TABELA 24 - EDITAIS: Inscrição de Bazar



{b} Nome Responsável Txt Simples - Recupera variável NOME +SOBRENOME da tabela usuário(apenas para visualização)

** Qual o nome do seu bazar? Txt Simples 100

** Materiais a seremcomercializados Txt Longo 512

(Citar quais materiais e aquantidade aproximada de cada.Ex: 300 camisetas, 50 bonés,1000 bottons, etc)

** Indique um link para podermosconhecer melhor seus produtos: Txt Simples 80

Opção para envio deinformações complementares aproposta, conforme disposto noedital.

** Qual o valor estimado que estátrazendo contigo em materiais? Txt Simples 50

** Que tipo de estrutura vocêprecisa? Txt Longo 256

** Conte-nos um pouco sobre oseu bazar.

Txt Longo 512

** Por que seu bazar deve estar noNDesign Imersão? Txt Longo 512

** Li e compreendi o edital deBazar [link]

CampoBooleano 1


ads/editais/n2010_bazar.pdf [botão] CONFIRMAR

Fonte: O autor.

3.3.10 Detalhamento das Telas

Cada página exibida ao usuário era resultado da união das várias partes da

estrutura que foram apresentadas nas anteriores.

As páginas eram dinâmicas e carregavam variáveis do banco de dados, de

acordo com fatores relacionados ao status da inscrição, data, vagas, todos estes já

apresentados anteriormente. Além disso, sempre que cada formulário fosse

carregado, o sistema deveria verificar se cada campo já foi previamente preenchido.

Caso positivo, deveria preencher o campo com o conteúdo armazenado de maneira

que o mesmo fosse editável, salvo em campos bloqueados.

Uma captura de tela para exemplo de cada uma das etapas foi realizada e

pode ser conferida no Apêndice 01. É possível que o leitor faça o login com um



90

usuário de teste para visualizar a interface em funcionamento real, basta utilizar os

dados abaixo:

Acesso ao SIU com usuário teste

(disponível até jan/2011)

Endereço: https://inscricoes.ndesign.org.br/

Login: 53571850858

Senha: 1234

3.3.11 Diagrama de Caso de Uso

Além da navegação básica no SIU, já demonstrada em resumo no subitem

3.3.7, foi necessário detalhar o relacionamento entre páginas e sub-páginas do SIU

e também rotinas e processos ocultos que eram realizados em cada etapa, como

pode ser observado na Figura 44.

FIGURA 44 - Detalhe do diagrama de caso de uso (Fonte: O autor)

O Diagrama de Caso de Uso completo está disponível no Apêndice 02. Para

possibilitar o seu entendimento são especificadas abaixo as principais ações que

ocorrem durante o processo de inscrição pelo SIU.

Botão OK/Confirmar/Enviar

Realiza o envio dos dados ao servidor para que seja passado a uma próxima



91

etapa. O rótulo do botão varia de acordo com o formulário em questão, porém a

ação é sempre a mesma: encerrar uma etapa com o objetivo de avançar.

Botão Salvar

Realiza o salvamento dos dados preenchidos no formulário em questão,

porém permanece na mesma etapa para continuidade da edição.

Caixa de Alerta

J anela pop-up que aparece na tela solicitando atenção ou confirmação do

usuário. É utilizada especialmente nas situações em que a ação solicitada nãopoderá ser revertida, ou então quando o usuário não realizou uma ação necessária

para prosseguir.

FIGURA 45 - Exemplos de caixa de alerta (Fonte: O autor)

Verificação de Campos

Sempre que o usuário enviar um formulário que conter dados relevantes os

campos correspondentes serão validados. Neste processo é verificado se os dados

inseridos são condizentes com o que foi solicitado, evitando que dados erradosfiquem armazenados no banco de dados. É também verificado se todos os campos

obrigatórios foram preenchidos. Somente após esta validação, caso todas as

exigências tenham sido atendidas, é que o formulário é enviado e armazenado no

servidor. Caso contrário é dado o retorno ao usuário através da marcação dos

campos incompletos e/ou caixa de alerta.



92

FIGURA 46 - Exemplo de feedback após verificação dos campos (Fonte: O autor)

Feedback ao usuário em tela

O feedback em tela é utilizado não somente para mensagens solicitando a

correção de campos, mas também para informar ao usuário uma ação realizada com

sucesso. Isso é interessante para que ele fique tranqüilo em relação à conclusão de

uma solicitação pessoal, como ocorre no envio de um formulário. Neste caso é

interessante que a mensagem seja exibida em local de destaque, porém sem

interromper a navegação, como acontece com uma caixa de alerta.

FIGURA 47 - Exemplo de feedback ao usuário em tela (Fonte: O autor)



93

Termo de Compromisso

Em algumas etapas do preenchimento da inscrição era necessário que o

usuário concordasse com um termo de compromisso específico. Este procedimento

visava resguardar a Comissão Organizadora de um eventual problema jurídico

posterior, e obrigava (ao menos na teoria) que o usuário lesse informações

importantes, regulamentos, condições e afins. Os termos de compromisso eram

exibidos em tela, ou em link disponível na tela e o usuário precisava marcar uma

checkbox em concordância ao disposto. Não era possível fazer o envio da etapa

envolvida sem a marcação desta checkbox.

FIGURA 48 - Termo de compromisso e caixa de alerta correspondente (Fonte: O autor)

Envio de informações por e-mail

Em algumas ocasiões o SIU se comunicava com o usuário através do e-mail

cadastrado, de modo automático:

Confirmação de e-mail (depois de preencher o cadastro básico), com um

link para ativação do cadastro, sem a qual o usuário não poderia utilizar o

sistema;

Envio de senha esquecida, com a respectiva senha;

Envio de cópia de edital submetido, para fins de conferência e

arquivamento do usuário e da comissão organizadora;



94

Envio de alterações salvas no edital de Chefe de Delegação, para fins

de conferência da comissão organizadora (este edital era o único que

possibilita salvamento sem envio definitivo).

FIGURA 49 - E-mail de ativação do cadastro básico (Fonte: O autor)



95

4 VALIDAÇÃO

Diversos teóricos ressaltam, com diferentes abordagens, a importância de

trazer o usuário para o centro do desenvolvimento. Isso pode ser observado nas

Regras de Ouro, propostas por Ben Shneiderman, em Designing the user interface

(1998), ou nas palavras de Mandel (1997), quando afirma que se adquirem

informações totalmente díspares dos decisores, em relação às informações

fornecidas pelos usuários reais dos produtos de tecnologia de informação. Ou ainda,

através das várias publicações de Nielsen, ao demonstrar perdas significativas que

as empresas têm ao desconsiderar a usabilidade que o sistema oferecerá ao

usuário.

Ressaltam-se também as palavras de Agner (2009), no fechamento de seu

livro "Ergodesign e Arquitetura de Informação: trabalhando com o usuário", ao

afirmar que ao deslocarmos o foco dos nossos projetos do sistema meramente

técnico para o ser humano, podemos ter uma importante contribuição a oferecer à

dinâmica de mudança das organizações e da sociedade, além do âmbito específico

do projeto das interfaces entre o homem e a tecnologia.

Com o objetivo de incluir o usuário, e tendo a oportunidade de fazê-lo a partir

de um sistema real e em funcionamento, neste capítulo veremos as etapas de

validação e seus resultados.

4.1 AVALIAÇÃO COM STAKEHOLDERS

Após o desenvolvimento preliminar do SIU-N2010 e antes da implementaçãofinal o sistema foi submetido para avaliação com stakeholders. Participaram desta

etapa 80 avaliadores, nos dias 11 e 12 de janeiro de 2010, sendo 60 membros da

própria comissão organizadora e 20 membros externos, aos quais foi pedido sigilo.

Com os avaliadores da própria Conde Curitiba o objetivo principal era perceber

pontos falhos em que o sistema não estivesse atendendo as próprias demandas da

organização. J á com os avaliadores externos o objetivo era perceber fragilidades do

sistema sob a ótica do usuário. Todos os avaliadores eram da área do Design(estudantes ou formados) e possuíam experiência em eventos de diversos portes,



96

tanto em participação como na organização destes.

A interface, ainda não totalmente funcional, mas com os elementos já

posicionados na sua versão final, foi implementada desta maneira em HTML, para

que os usuários abrissem as páginas do sistema em seus diferentes navegadores.

Esta versão beta foi agrupada em um arquivo compactado e distribuída para todos

os avaliadores, sem explicações sobre o porquê dos elementos, para utilização

como um usuário qualquer, que faz o uso sem instruções além do veículo em si.

FIGURA 50 – Pacote de arquivos enviados para os stakeholders (Fonte: O autor)

FIGURA 51 – Página de exemplo de interface enviada para os stakeholders (Fonte: O autor)



97

Em relação à interface principal os principais comentários recebidos foram

sobre a legenda e menu superior. Foi ainda questionado o formato dos botões e a

necessidade de ênfase tão grande na sequência dos passos. O destaque foi mantido

justamente pelo objetivo de direcionar a atenção do usuário para este elemento da

interface. No entanto, ainda em relação ao menu superior, algumas críticas foram

consideradas, em especial sobre os rótulos. Um dos avaliadores até lidou com este

item de maneira lúdica, conforme mostra a Figura 52, ao demonstrar a necessidade

de alinhamento dos rótulos externos e internos de cada botão.

FIGURA 52 – Observação sobre posicionamento dos rótulos do menu superior feita por um avaliador

(Fonte: O autor)

Ainda em relação aos rótulos, os mesmos tiveram o tamanho de corpo de

texto reduzido. O texto do rótulo da legenda foi mudado, para torná-la mais

conectada com seu significado, passando de “legenda” para “legenda – passos e

editais”.

FIGURA 53 – Correções efetuadas no menu superior do SIU (Fonte: O autor)

Foram ajustados vários pontos do código-fonte das páginas para permitir uma

visualização adequada do conteúdo, pois alguns navegadores estavam

interpretando o posicionamento dos elementos de modo equivocado, fazendo com

que o botão de editais pudesse aparecer em uma segunda linha. Além disso, foi

corrigido o layout dos botões “sair”, “ajuda” e “editais”, que na sua lateral direita

possuíam uma curvatura que extrapolava os limites da grade do design estrutural,

além de estarem destoantes com o resto da interface, como pode ser observado na

Figura 54.



98

FIGURA 54 – Erros de quebra de linha e curvatura dos botões (Fonte: O autor)

As páginas do cadastro básico sofreram mudanças estruturais. Inicialmente a

previsão era de apenas um campo na primeira página, para entrada do CPF. Com a

verificação do campo o próprio sistema identificaria se o usuário já estava

cadastrado ou não, redirecionando para a página com o campo de senha ou com os

campos do cadastro básico. Como não houve entendimento, adotou-se

posteriormente a primeira tela com as perguntas “J á estou cadastrado” e “Quero me

cadastrar”, cada qual com link para a página correspondente.

FIGURA 55 – Tela inicial do SIU decidida pela verificação de CPF (Fonte: O autor)

Para a verificação e ativação dos e-mails enviados pelo cadastro básico,

inicialmente foi previsto um campo para preenchimento de código de confirmação.

Este ponto gerou dúvidas durante a validação, por isso na versão que foi ao ar, após

o envio do cadastro básico é apenas informado que um e-mail de confirmação foi

enviado, pedindo que o usuário verifique seu e-mail. Assim, a ativação é feita por um

link nesta mensagem de e-mail, que quando clicado redireciona para a página de

login, com o feedback da ativação realizada com sucesso.



99

FIGURA 56 – Versão preliminar da ativação de cadastro com código a ser digitado (Fonte: O autor)

A página do Passo 3 foi a que mais teve alterações nesta validação. Na

primeira versão ela agrupava a seleção de pacotes e forma de pagamento em uma

mesma página, como pode ser conferido na Figura XX. A partir do feedback desta

avaliação e por uma indicação do programador, houve a separação em páginas

distintas, porém mantendo um único botão de acesso no menu superior.

FIGURA 57 – Versão agrupada da página do Passo 3 (Fonte: O autor)



100

Além das sugestões de alteração estrutural, de layout e interface já

apresentadas, recolheu-se durante esta validação uma série de anotações sobre

correções necessárias na redação de itens do formulário. Alguns campos foram

adicionados ou retirados, e outros tiveram itens reformulados. Nesse aspecto a

avaliação com stakeholders foi bastante valiosa, pois foi considerada a opinião de

usuários experientes, conferindo mais abrangência e consistência à primeira versão

que posteriormente foi ao ar, no lançamento do SIU-N2010.

4.2 ESTATÍSTICAS GERAIS

4.2.1 Estatísticas Finais dos Cadastros do SIU-N2010

Neste item analisaremos algumas estatísticas relacionadas ao SIU-N2010,

fornecidas pela Conde Curitiba após a finalização do evento. São números que não

foram contabilizados e disponibilizados na íntegra em edições anteriores,prejudicando os novos organizadores, que a cada ano trabalharam com estatísticas

bastante imprecisas, colocando em xeque o planejamento estrutural do evento.

TABELA 25 – Estatísticas Finais do SIU-N2010

USUÁRIOS PACOTES SUBMISSÕES DE EDITAIS

Cadastros totais 6570 Inscrição Básica 4340 Mergulho 225Ativos 6363 Alimentação NãoVegetariana 2955 Quebrando o Gelo 19

Censo completo 5775 Alimentação Vegetariana 365 SEPA 112Enviaram edital 620 Alimentação Total 3320 Mostra de Vídeos 31Participantes do N 4547 Alojamento 2648 Representante do Cone 26

Festas 3620 Chefe de Delegação 52Monitoria 254Bazar 39

Pagamento de Inscrições: R$ 638 860.00TOTAL 758

Fonte: O autor.

Observa-se que o banco de dados possui um total de 6570 cadastros, umnúmero 44,49% superior ao de participantes do N2010, que é de 4547. Porém, do



101

total de cadastros, muitos deles não passaram sequer da ativação do e-mail

informado, ou seja, 96,85% preencheu apenas o cadastro básico, sem ter acessado

o PASSO 1. Considerando os cadastros ativos (6363) somente 90,76% deles

continuou até a etapa do preenchimento completo do PASSO 2 – Censo. Disto

conclui-se que o total dos usuários que completou o PASSO 2, 5775 cadastros, são

referentes a pessoas que de fato almejavam participar do evento, porém, por algum

motivo, 27% deles não finalizaram sua inscrição posteriormente. São cadastros

completos, aptos para efetuar o pagamento ou submissão de editais, mas que não

concluíram a inscrição.

Em relação ao número de participantes efetivos do N Design observa-se que

13,64%, ou seja, 620 usuários submeteram algum edital para avaliação. Como onúmero total de propostas submetidas é de 758, conclui-se que 22,26% destas

foram enviadas por usuários que submeteram mais de uma proposta, em editais

diferentes ou iguais.

O número de participantes oficial do N Design foi 4547, mas, apenas 95,45%

destes possuem registro de confirmação de isenção ou pagamento efetuado, ou

seja, 4340 inscrições básicas. Os pacotes opcionais, em relação ao pacote

obrigatório, obtiveram boa adesão: Alimentação com 76,50%; Alojamento com61,01% e Festas com 83,41%. Considerando as 2 opções de cardápio para o Pacote

de Alimentação observa-se que 89% selecionou a opção não-vegetariana e 11%

selecionou a opção vegetariana.

Por fim, observa-se que o montante total de entradas relativas ao sistema de

inscrições é de R$638.860,00. Trata-se de um valor considerável, o que reforça

aquilo que já foi citado neste projeto: a importância e responsabilidade no

desenvolvimento de um sistema e banco de dados seguro e consistente.

4.2.2 Estatísticas de acesso e perfi l do usuário

Neste item serão apresentados alguns resultados fornecidos pelo Google

Analytics®, sistema de análise de métricas gratuito que foi utilizado para

acompanhamento dos acessos ao site do N Design Imersão 2010. Foi considerado o

período de 01 de fevereiro de 2010 a 18 de julho de 2010, referente a um número

total de 205.448 visitas e 640.167 páginas visualizadas.



102

FIGURA 58 – Análise de métricas do site do N2010 (Fonte: O autor)

No gráfico do número de visitas ao longo do período observa-se uma

dinâmica de variação significativa das visitas a cada semana, em função do númeromais elevado de visitas no início da semana e mais reduzido no final de semana. O

pico foi de 4244 visitantes, no dia 09 de julho. Logo após a página principal (/2010),

que aparece com 33,35% das páginas visualizadas, vem justamente a página de

entrada do Sistema de Inscrições Unificado (/2010/inscricoes), com 8,95% e um total

de 57.267 visualizações/acessos1.

FIGURA 59 – Análise de métricas da página de entrada do SIU (Fonte: O autor)

1 Será utilizado o termo “acesso” ao invés de “visualização” ou “página visualizada”, referente ao termo original“pageview”, que aparece nos gráficos do Google Analytics.





104

onde o Internet Explorer lidera. No entanto, 29,42% dos usuários ainda utilizam o

Internet Explorer, algo que deve ser considerado pelos desenvolvedores, uma vez

que este navegador possui algumas limitações na interpretação do código-fonte e

especialmente na interpretação de scripts, como o javascript, utilizado na máscara

de alguns campos do SIU-N2010.

FIGURA 61 – Análise de métricas do SIU por navegador (Fonte: O autor)

O Google Analytics também fornece a estatística dos usuários com e sem

suporte para J ava. A estatística alarmante é que 13,95% não estava com suporte

ativado no momento de entrada da página de inscrições. Depois de alguns

problemas foi inserida uma limitação no SIU e usuários que não habilitassem o J ava

não poderiam acessar o sistema.

FIGURA 62 – Análise de métricas do SIU por suporte a J ava (Fonte: O autor)

O último item a ser conferido é a resolução da tela. Durante o

desenvolvimento se convencionou que seria utilizada como referência mínima a

resolução de 1024x768px. Esta convenção foi adotada para todo o site do N2010 e

também para o Sistema de Inscrições. Em resoluções menores do que esta os

usuários poderão enfrentar problemas ou dificuldades de visualização de todos os

elementos em tela. Através das estatísticas percebe-se que foi uma decisão

acertada. A resolução de 1024x768px foi a mais utilizada com 25,53%, seguida de

1280x800px, com 23,31%. Estas resoluções são as mais utilizadas em

computadores desktops e portáteis, respectivamente. Nota-se que a única resolução



105

que não atende o requisito mínimo, e que aparece entre as 15 mais utilizadas, é a

“800x600px”, em 14º lugar, com 1% dos acessos, o que não chega a ser um

problema.

FIGURA 63 – Análise de métricas do SIU por resolução de tela (Fonte: O autor)

As análises deste item poderiam se estender bastante. O Google Analytics

oferece uma excelente tecnologia que pode ser aproveitada pelos futurosorganizadores. Trata-se de um mecanismo eficaz para observar o perfil do usuário,

mas não só isso, pois através da análise de métricas é possível mapear todo o perfil

de acesso ao site, página de origem e destino dos visitantes, tempo de acesso,

retornos, novos visitantes, retorno de pesquisas por palavras-chave, e dezenas de

outras opções. Neste projeto a análise foi limitada aos fatores de maior relação com

o SIU-N2010.

4.3 QUESTIONÁRIO DE SATISFAÇÃO DO USUÁRIO COM A INTERFACE

O primeiro instrumento de análise previsto neste trabalho foi realizado a partir

de uma adaptação do QUIS - Questionnaire of User Interface Satisfaction de Ben

Shneiderman (1998). A maior parte do modelo original foi mantida, a partir de

tradução livre do inglês para o português e com a alteração de parte da terminologia

utilizada. O QUIS foi utilizado nesta etapa do desenvolvimento visando obter, de

maneira rápida, um diagnóstico completo da opinião do usuário em relação a vários



106

aspectos da interface do sistema analisado.

Das 12 partes do modelo original foram adaptadas e utilizadas apenas 7:

1ª Parte: Experiência com o Sistema;

2ª Parte: Experiência Anterior;

3ª Parte: Impressões Sobre a Utilização do Sistema;

4ª Parte: Tela;

5ª Parte: Nomenclatura e Sistema de Informação;

6ª Parte: Aprendizagem;

7ª Parte: Capacidades de Sistema.

Foi ainda criada a 8ª Parte: Considerações Finais, com o objetivo de estimularo usuário a relatar itens em uma última questão aberta, visando contribuições que

poderão auxiliar diretamente no momento de escolha de parâmetros para o redesign

da interface.

Desconsiderando o cabeçalho, que possui 2 perguntas para traçar o perfil do

usuário (Idade e Gênero), o instrumento de pesquisa foi finalizado com 63 perguntas

fechadas, sendo na sua grande maioria escalas de oposição semântica numeradas

de 1 a 5, e, sete questões abertas, com o objetivo de coletar informaçõescomplementares e sugestões específicas para determinadas partes.

Foi utilizada a tecnologia de formulário eletrônico do Google Docs®, que

permite rápida implementação, fácil distribuição on-line e possui um sistema eficiente

para controle de quantidade de respostas e exibição dos resultados. Seguidores das

Redes Sociais Twitter ® e Orkut®, relacionadas ao N Design, foram convidados a

participar voluntariamente respondendo o questionário, disponibilizado na internet

durante 4 horas de um único dia, em junho de 2010, durante o período final dasinscrições do SIU. O curto tempo foi suficiente para se obter uma amostragem de

20 participantes, que será analisada a seguir. O formulário pode ser verificado em

sua íntegra no Apêndice 03 e a compilação da amostra no Apêndice 04.

Observa-se que os participantes estão distribuídos quase que igualmente

entre os gêneros e que as faixas etárias correspondem de fato ao principal público-

alvo do Sistema, jovens de 18 a 30 anos.



107

FIGURA 64 – Resultado QUIS: Idade e gênero (Fonte: O autor)

Na questão 1.1 nota-se que a maioria (N=15) dos usuários utiliza o sistema de1 a 6 meses e que metade deles (N=10) já utilizou o sistema 6 ou mais vezes, o que

aumenta a probabilidade de respostas coerentes no resto da pesquisa. Outro dado

interessante é que a maioria (N=16) já utilizou pelo menos algum outro sistema

semelhante, o que reforça o resultado como uma boa possibilidade de contribuição

direta para o desenvolvimento do projeto.

FIGURA 65 – Resultado QUIS: Tempo de uso e quantidade de visitas (Fonte: O autor)

Ressalta-se que 55% dos usuários afirmam que nenhuma vez tiveram

problemas com o sistema, apenas 1 afirma ter possuído problemas entre 3 e 5 vezes

e outro mais de 10 vezes. O resultado desta variável pode ter sido determinante para

o que percebe-se nas questões seguintes, onde praticamente a totalidade dasafirmações é associada aos extremos positivos das escalas.



108

FIGURA 66 – Resultado QUIS: Quantidade de problemas enfrentados pelo usuário (Fonte: O autor)

Na 3ª Etapa a questão 3.1 e 3.2, sobre reações ao sistema, teve um dos

piores resultados na amostra, merecendo atenção no caso de um desenvolvimento

futuro de aprimoramento do SIU. Aqui percebe-se a escala com respostas próximas

aos extremos negativos da grade (tedioso, rígido e ilógico).

FIGURA 67 – Resultado QUIS: Reações negativas ao sistema (Fonte: O autor)



109

FIGURA 68 – Resultado QUIS: Sistema Unificado é lógico ou ilógico? (Fonte: O autor)

J á na 4ª Parte: Tela, os pontos que merecem maior atenção são: 4.3 –

Layouts das telas facilitam, onde 35% se posicionaram de maneira neutra (ponto

central da escala); 4.3.1 – Quantidade de informação que pode ser apresentada na

tela, onde 15% assinalaram respostas próximas ao extremo negativo (inadequada) e

20% foram neutras;

FIGURA 69 – Resultado QUIS: Reações ao Layout (Fonte: O autor)

Ainda na 4ª Parte, mais 2 pontos merecem atenção. 4.2.1 – Organização da

informação na tela, onde 20% tenderam para o extremo negativo (ilógica); e 4.4.2 –

Voltar para a tela anterior, onde 20% tenderam para o extremo negativo (impossível);



110

FIGURA 70 – Resultado QUIS: Reações à navegação (Fonte: O autor)

Mesmo que em resultado pouco expressivo, com 5 a 10% da amostra, é

possível notar alguns pontos criticados nas questões da 5ª Parte, com relação à

nomenclatura, feedback, comandos, quantidade e posicionamento das informações

e redação das mensagens de erros. O mesmo pode ser observado em questões da

6ª Parte, no que tange ao início da utilização, aprendizado de recursos avançados e

estímulo de exploração de recursos por tentativa e erro.

Destaca-se uma atenção necessária para alguns pontos que podem ser mais

críticos: 6.2.2 – Descoberta de novos recursos, onde 20% se posicionaram próximoao extremo negativo (difícil); 6.4.1 – Número de etapas por tarefa, onde 10% ficaram

próximas ao extremo “demasiado” e 35% foram neutras, representando quase

metade da amostra.

FIGURA 71 – Resultado QUIS: Sobre a aprendizagem da interface (Fonte: O autor)



111

Finalmente, na 7ª Parte: Capacidades do Sistema, é necessária atenção no

item 7.2.2 – Aviso de potenciais problemas, onde 15% relataram opinião próxima ao

extremo negativo (nunca) e 35% se posicionaram de maneira neutra.

FIGURA 72 – Resultado QUIS: Aviso de problemas potenciais (Fonte: O autor)

Além dos fatores acima, analisados a partir das questões fechadas, observa-

se uma boa participação nas questões abertas com 75 respostas ao todo, as quais

oferecem inúmeras contribuições para a pesquisa e podem ser conferidas em sua

íntegra no Apêndice 05.

4.4 FEEDBACK DE ATENDIMENTO AO USUÁRIO

Nesta etapa de validação foram compilados todos os atendimentos ao usuário

realizados por e-mail pela Comissão de Tecnologia e Informação da Conde Curitiba,

principal responsável pela recepção e solução de dúvidas e problemas enfrentados

com o Sistema de Inscrições Unificado. Outros canais de comunicação também

foram utilizados: e-mail da Comissão de Assessoria ao Encontrista (focado em

dúvidas sobre o evento em si); e-mail geral ([email protected],

geralmente repassado às Comissões responsáveis); chat semanal (realizado no site

do N2010); redes sociais; contato telefônico; e até pessoalmente, direto com os

membros da organização. Estes canais secundários possuem amostra menor e não

serão analisados neste projeto.

Para a análise foi cedido pela Conde Curitiba o acesso ao e-mail da

Comissão de TI, onde estavam armazenados 1736 tópicos de atendimento. Em 76%



112

deste montante foram localizadas dúvidas sobre o Sistema de Inscrições Unificado,

totalizando 1326 chamados de atendimento realizados entre 29 de janeiro de 2010

e 29 de julho de 2010, 6 meses de suporte.

Cada novo item encontrado foi inserido em uma planilha com sua descrição,

elemento associado e sugestões de soluções feitas por ocasião deste trabalho.

Posteriormente, os chamados de atendimento foram categorizados para facilitar o

entendimento da distribuição dos pontos de dúvida entre os itens do sistema, como

poderá ser observado nas tabelas a seguir. O objetivo aqui não é o detalhamento

completo de cada ponto e o desenvolvimento da possível resolução do problema,

mas sim, o levantamento de problemas encontrados pelo usuário, de modo que os

próximos sistemas possam considerar estes dados em seu desenvolvimento,previnindo a repetição dos mesmos itens.

TABELA 26 – Feedback Usuário: Cadastro Básico

PONTO PROBLEMAS ELEMENTOS MELHORIAS qtde

Ativação de e-mail

E-mails caindo nacaixa de SPAM;Servidor na lista negrade envios;Hotmail e Yahoorecusando mensagens

EspecificaçõesFuncionais

Adotar política anti-spam;Opção administrativa paraativar;Aviso na tela de maneira ainda

mais expressiva;Preencher CPF para formuláriode dúvidas;

81

Erro em dadosbloqueados

Usuário errou nopreenchimento dedados bloqueados

Design daInformação

Diferenciar campos bloqueados;Interface administrativa paracorreção

32

Erro nopreenchimentode e-mail

Erros de digitação;Uso de e-mailsecundário;

Arquitetura daInformação;Design Visual

Diferenciar campos bloqueados;Especificar que o e-mail seráverificadoCitar "seu e-mail é xxx?" na janela de alerta antes deconfirmar o envio do formulário

32

Erro nopreenchimentode nome

Erros de digitação;Nomes repetidos noscampos de nome esobrenome;Esquecimento donome do meioUso de nome artísticoao invés de nome real.

Arquitetura daInformação;Design Visual

Diferenciar campos bloqueados;Campo "nome do meio"Campo "nome artístico" paraatividadesEspecificar que o nome seráusado tal qual preenchido nocertificadoCitar "seu nome é xxx?" na janela de alerta antes deconfirmar o envio do formulário

21

Subtotal 166

Fonte: O autor.



113

TABELA 27 – Feedback Usuário: Pagamentos


DocumentoComprovante dePagamento

Dúvidas sobre ocomprovante depagamento paragarantir a inscrição doevento

Design daInformaçãoDesign VisualEspecificaçõesFuncionais

Opção de gerar documento deconfirmação, um “ingresso” doevento;E-mail confirmando opagamento recebido comsucesso e explicando as formasde comprovação; Tornar o Passo 3 clicável paraver detalhes do pagamentoapós realização do mesmo;Citar pacotes que foramconfirmados e pagos;

119

Refazerpagamento ouforma depagamento

Dúvidas e pedidosdiversos sobre comorefazer pagamento ouforma de pagamento,uma vez que esteestivesse gerado

EspecificaçõesFuncionaisDesign daInformação

Deixar mais claro na interface oprocedimento para refazer o

pagto;Alterar rótulo do botãoquando o pagamento estávigente para “reimprimirboleto”;Opção de refazer pagtozerando o outro (risco dousuário);Informações sobrepagto expirado e providênciasenviado para o e-mail.

79

Como pagar econfirmarpagamento

Dúvidas sobre prazode vencimento;Não saber ondeacompanhar opagamento;Não saber como equando confirmar opagamento;Desconhecimento dedias úteis e não úteispara pagamentos.

Design daInformaçãoEspecificaçõesFuncionais

Envio de e-mail com todas asinformações sobre opagamento, prazos, formas deconfirmação;Sistema que gere boletodesconsiderando dias não úteis;Diferenciar de maneira maisexplícita prazo de pagto deprazo de verificação de pagto.Informar sobre formas econdições de pagamento logono início do cadastro;Informar que são 2 dias parapagto antes do usuário emitir opagto.Opção de enviar boleto no e-mail

74

Nova janela depagamento

J anela pop-up quenem sempre abre

EspecificaçõesFuncionaisDesign Visual

Alerta diferenciado “verifiqueseu bloqueador de pop-up”;Explicar como desabilitar obloqueador de pop-up Trocar janela pop-up por outratecnologia;

60

Refazerpagamentovencido

Dúvidas sobre comorefazer ou pagamentovencido ou solicitaçõesde refação

EspecificaçõesFuncionaisDesign daInformação

Deixar claro o prazo devencimento do boleto;E-mail automático cominformações sobre o vencimentodo pagamento

41



114


Demora na

integraçãobancária

Problemas decorridoscom a demora deconfirmação depagamentos no boleto


Não utilizar sistema de boleto dobanco;Feedback em tela sobre data

dos últimos pagamentosatualizados, ranqüilizando ousuário;Aumentar o plantão da equipe.

22

Forma decobrança efuncionamentodo PagamentoDigital

Dúvidas em geralsobre a forma depagamento parceladono PD e problemasdecorrentes daintegração dos

sistemas


Página com informações sobreo funcionamento do PagamentoDigital;E-mail avisando sobre oprocesso da verificação dedados;Integrar para ter resposta do PDdireto no status de pagamentodo SIU;Verificar de tempos em temposse houve alterações nastransações do PD.

20

Envios decomprovantesparaorganização

Alguns usuáriosenviaramcomprovantes por e-mail


Explicação no site/e-mail quenão é necessário enviar ocomprovante para organização

19

Controle depagamentos dosistema

Ausência de feedbackao usuário durante operíodo deconfirmação;Ausênciade verificação de

pagamentos em abertopor muito tempo.

Design daInformaçãoDesign de Interação

Melhorar feedback textual/visualsobre pagamento em aberto/emanálise;Enviar e-mail parapagamentos em aberto e já

vencidos, explicando o quefazer

19

Prorrogação doLote 3

Dúvidas relativas aprorrogação do Lote 3

Design daInformaçãoDesign Visual

Em caso de prorrogação,corrigir datas e lançar o informeem todas as mídias e tbm nopróprio sistema

17

Simulação xpagto iniciado xinfos

Não entendimento dousuário sobre adiferença entre simulare efetuar umpagamento


Alerta de efetuação depagamento (e não simulação);Explicar formas de pagtoeparcelamento antes de abrir osistema de inscrições;

14

Troca de Lote dePagamento

Usuários que deixarampagtos vencerem e nãoentenderam valoracrescido em funçãoda mudança de lote


E-mail automático avisando que

o Lote está acabando e que ovalor acrescido caso não hajapagamento confirmado noprazo;Informação adicional em tela.

11

InscriçõesPresenciais

Dúvidas sobre comofazer inscriçãopresencial


Explicação do procedimento nosite e no SIU 11

Confirmaçõesem final de lotede inscrições

Usuários que deixarampra resolverpendências em cimada hora do fim do lote


Feedback com informação emtela ou email falando do final dolote, com alguns dias deantecedência

10



115


Pagto Inativo eperda depacotes

Erro de sistema queocasionou adesativação de

pagamentos, queentão não reconheciama confirmação.Usuários desatentos,ao tentar refazer,apagavam sua seleçãode pacotes, quebrandoo sistema


Cuidar com automações dosistema, guardar datas e ações

e nunca apagar entradas dobanco de dados (apenasdesativá-las);Sistema checa, antes de refazerpagamentos e pacotes, se alémda entrada está inativa, não hápagamento confirmado

9

Boleto incorreto

Casos de boletosemitidos e não aceitospor determinadosbancos, no início dasinscrições


Checagem mais detalhadaantes da liberação do sistema 8

Boleto de10milhões

Erro de sistema queem situaçõesesporádicas gerava umboleto de 10milhõesem caso deinconsistência dosdados para emissão(acontecia as vezesquando o sistemexpirava)


Mensagem de erro em tela aoinvés de gerar boleto com erro,e opção de refazer.

4

Pagamento emduplicidade

Falha do sistema quepermitiu que alguns

usuários conseguissemter mais de 1pagamento ativo aomesmo tempo


Verificação que não permitagerar 2 pagamentossimultâneos ativos

3

Subtotal 540

Fonte: O autor.

TABELA 28 – Feedback Usuário: Pacotes


Seleção depacotes

Usuário errou naseleção de pacotes equer refazer


Possibilidade de refazer aseleção se não houverpagamento ativo (esta opção foiimplementada durante oandamento das inscrições)

69

Pacotes avulsos

Usuário não comproutodos os pacotes deuma vez só e queincluir novos pedidos epagamentos

Design daInterfaceDesign VisualEspecificaçõesFuncionais

Opção de comprar pacotesavulsos separados após ainscrição principal, já integradaao SIU, de modo automático.

35



116


Alteração depacote dealimentação

Trocas entrevegetarianos e nãovegetarianos por

revenda de inscriçõesou casos de erro depreenchimento (algunspor falha do sistemacom parte em java)

Design da

InterfaceDesign VisualEspecificaçõesFuncionais

Deixar opção para o usuárioalterar pacote por conta própria

até uma data limite;Deixar mais clara e diferençaentre os pacotes;Opção administrativa que tornea alteração mais fácil

19

Ingressosavulsos

Dúvidas sobre a vendados ingressos avulsospara cada festa depoisque o pacote de todaselas acabou


Melhorar a disposição dainformação e colocar uma notasobre esta opção no sistema

11

Dúvidas sobrepacotes

Ausência deexplicação sobre o que

são os pacotes diretono SIU (estaexplicação estavaapenas em páginaprópria)

Design daInformaçãoDesign deNavegação

Interligar páginas específicas

com informações dos pacotes;Explicar que o pacote dealojamento é individual (e nãopor barraca)

5

Subtotal 139

Fonte: O autor.

TABELA 29 – Feedback Usuário: Editais


Correção deEditais jáenviados

Após enviados oseditais nãopossibilitavamalterações, devido aestarem em análise.Qualquer correçãotinha que ser pedidaatravés de e-mail


Melhorar interface administrativapara alteração dos dados pelaorganização

41

Confirmação desubmissão

Não havia umfeedback claro sobre a

submissão comsucesso, apenas umatela com a listagemdos editais submetidos

Design daInformaçãoDesign daInterfaceDesign VisualEspecificaçõesFuncionais

Informação clara se o formuláriofoi enviado ou não; Texto padrão na tela principal deeditais de quem não feznenhuma submissão;

26

Tempo deexpiração desessão

Devido a um erro deprogramação o tempode expiração dasessão logada ficousetado em 30 min, oque causou a perda deformulários de editais


Aumentar o tempo de sessão(posteriormente foi aumentadopara 120min); Ter um relógio que demonstra otempo da sessão, como emsistemas bancários

23



117


Dúvidas sobreinscrição comeditais

Dúvidas de usuáriosconfusos sobre

inscrição pra quemestá nos editais

Design da

Informação

Enviar principais orientações pore-mail além de solicitar a leiturado edital de instruções

completo;Repensar o rótulo “Editais”, quepode não estar claro.

22

Conflito compagamento ativo

Alguns usuáriossubmeteram editaiscom pagamento ativomas não efetuado eisso travou o sistemaquando estes foramconfirmar a isençãopela aprovação ou agarantia de lote na nãoaprovação


Verificar garantia de lote econfirmação de isenções antesda liberação do resultado doseditais;Verificar pagtos ativos e nãofinalizados, tornando-osinativos;Aprimorar mensagens de statuspara usuários de editais, comestágios intermediários

10

Procedimentoaos aprovados enão aprovados

Demora na divulgaçãodos procedimentos,que gerou dúvidas logoapós a divulgação dosresultados


Acelerar a divulgação dosprocedimentos, fazendo-asimultaneamente ao resultadoda seleção

9

Apagar/cancelareditais enviados

Pedidos para apagareditais enviados,quando na verdade opróprio usuário poderia

fazê-lo pela interface


Mostrar que dá pra apagar umedital por conta própria, a partirda interface, em um e-mailexplicativo;Em caso de cancelamento ouexclusão, enviar e-mail paraorganização e para o usuário,

não apagando totalmente dobanco de dados, apenasalterando o status paraeventuais correções de erros

7

Pagamento egarantia de lote

Dúvidas sobre comoefetuar o pagamento egarantia de lote aosnão aprovados


Perceber quando existe umpagamento em paralelo ecolocar orientação em tela e pore-mail

5

Anexo Editais

Na maioria dos editaishavia um campo“Anexo” para enviarinformações

complementares paraanálise. Porém estecampo não tinha sidoreferenciado nomaterial informativo


Explicar melhor para que serve

o campo anexo de cada um doseditais 5

Membros deDelegação

No edital de Chefe deDelegação o campo deinserção do CPF dosmembros permitia quefosse inserido “-“ aoinvés de ser somentenúmeros, assimusuários desatentos aoaviso não localizam omembro do CPFespecífico


Utilizar campo de CPF conformelogin, permitindo somentenúmeros

4



118


Limite de

caracteres

Alguns campos doseditais foram alvo de

reclamações por terum limite pequeno decaracteres



Aumentar o limite de caracteresde alguns campos (jáimplementado);

Ter explícito no formulário olimite de caracteres de cadacampo.

3

Erro Mostra deVídeos

No edital de instruçõesas categorias eramdiferentes daquelasdispostas na seleçãodo formulário, por umerro de comunicação efalha de verificação


Ter mais atenção na correçãodos formulários antes dapublicação

3

Alteração detitular de edital

Pedidos de alteração

de titularidade de umusuário para o outro


Explicar melhor que não serãopermitidas alterações de

titularidade;Opção administrativa paraalteração de titularidade

3

E-mail defeedbackerrados

Alguns e-mails defeedback de inscriçãoestavam sendoenviados com camposfaltantes, devido aimplementaçõesintermediárias dosistema

Arquitetura daInformação

Não alterar o sistema no meiodas inscrições;Verificar envios aos usuáriosapós modificações necessárias

2

Ressarcimento Dúvidas em geral

sobre ressarcimento

Design da

Informação

Informação clara nos

procedimentos

2

Carta de aceitePedidos de envio decarta de aceite dotrabalho aprovado


Opção de gerar carta de aceiteautomática na interface 2

Subtotal 167

Fonte: O autor.

TABELA 30 – Feedback Usuário: Limitações SIU-N2010


Revenda deInscrições

Usuários desistentesque não querem perdero investimento,transferindo a suainscrição

Design daInformaçãoArquitetura daInformaçãoEspecificaçõesFuncionais

Deixar claro que não haveráreembolso;Opção de revenda no próprioSIU, ou link com informaçõespara procedimentos;Disponibilizar previamentemodelos de documentos derevenda no site;Esclarecer que somente 1pacote não poderá serrevendido;

97



119


CertificadosPedido de Envio deCertificados após o

evento

Arquitetura daInformaçãoEspecificações

Funcionais

Opção de emitir certificadodigital pelo sistema salvando-o

em PDF

60

Cadastro deEstrangeiros

Os estrangeiros semCPF não poderiam secadastrar no sistema,exigindo um cadastromanual pelaorganização

Arquitetura daInformaçãoEspecificaçõesFuncionais

Versão de login que não sejabaseada em CPF; Tradução dos Campos;Gerador de CPF aleatórioembutido para uso dosestrangeiros;

18

ProgramarIsenções

Pedido deConfiguração deIsenções paraparceiros e demaisisentos for a dos

editais


Opção administrativa paraconceder uma isenção a umdeterminado CPF/usuário, porpacotes e porcentagem

17

Documentaçãodos menores deidade

Dúvidas sobreprocedimentos aosmenores de idade

Design daInformaçãoArquitetura daInformaçãoEspecificaçõesFuncionais

Sistema programado para avisaro usuário sobre questõesespecíficas aos menores deidade, caso identifique peloformulário que o usuário nãocompleterá a idade mínima atéo evento

7

Boleto comCNPJ

Empresas solicitandoemissão de boletoscom seus dados parapagamento de

inscrição defuncionários

Design daInformaçãoArquitetura da

InformaçãoEspecificaçõesFuncionais

Opção administrativa ousecundária ao usuário paragerar boleto com dados

específicos

7

Publicização deEstatísticas

Alguns outrosorganizadores e lídereslocais se interessavamem saber estatísticassobre o andamentodas inscrições em suascidades


Informar boletins comestatísticas com maiorperiodicidade

6

Número decadastro

Solicitação de algunsusuários parareceberem seusnúmeros de cadastro


Inclusão de campo na interfacee nos e-mails que informe onúmero de cadastro (ID) dousuário

3

Cancelamentode Cadastro

Pedidos para exclusãodo cadastro do bancode dados


Opção administrativa paraexcluir totalmente os registrosassociados a um usuário, comas devidas restrições de umaação que não será retornável

1

Subtotal 216

Fonte: O autor.

TABELA 31 – Feedback Usuário: Dúvidas em geral




120


Dúvidas emgeral

Dúvidas que poderiamser esclarecidas peloFAQ


Melhorar a apresentação eorganização do FAQ 19

CredenciamentoDúvidas sobre ocredenciamento noinício do evento

Design deInteração

FAQ enviado por e-mail comalguns dias de antecedência aoevento

13

Botão salvar eenviar

Alguns usuários nãoentenderam adiferença entre o botãosalvar e enviar, e nãoconseguiam avançarno preenchimento doformulário


Mudar rótulo dos botões;Mudar mensagem de status;Mudar mensagem de feedbacke da janela de alerta para tornarexpressa a ação do botão(alteração realizada)

10

Valores deinscrição e

forma depagamento

Dúvidas sobre dados

que já estavaminformados no site Design Visual

Refazer o redesign da páginaque antecede o SIU;

Criar guia passo-a-passo paracalouros de evento

6

Documentosfaltantes

Usuários que nãoconseguiam preenchero cadastro devido aausência dedocumentosobrigatórios

Requisitos deConteúdo

Rever necessidade de camposespecíficos de documentaçãocomo “data de expedição” doRG e outros dados quepoderiam ser dispensáveis

6

Recuperação desenha

Solicitação de senhapor e-mail quando naverdade o sistemaoferece esta opção


Repensar o botão eposicionamento da opção de“esqueci minha senha” einformar este procedimento na

seção “ajuda” do site e do SIU

6

Solicitação dealteração dedados

Usuários quesolicitaram alteraçãoem campos editáveis,onde não haviabloqueio


Deixar claro que é possívelalterar dados e atualizar ocadastro, podendo ser enviadoum mailing ao final dopreenchimento, informando quea interface pode ser utilizadapara atualização

4

Dúvidas sobretipo de inscrição

No N2010, diferentedos últimos anos, nãohavia diferenciação dainscrição para

estudantes eprofissionais


Comunicar claramente seexistem, ou não, distinção deinscrição e preços paraparticipante estudante ou já

formado.

4

Promoçãocachecol

Dúvidas sobre osganhadores docachecol na promoçãodos 500 primeiros, quedemorou a serdivulgada


Mensagem na interface principale e-mail, em paralelo aconfirmação de pagamentorealizada

4

Dúvidas sobre ainterfaceunificada

Onde paga? Ondeenvio oficina? Etc.


Guia básico sobre o SIU,especialmente para os calouros,indicando as etapas e utilidadesda interface

4

Subtotal 76

Fonte: O autor.



121

TABELA 32 – Feedback Usuário: Erros de sistema


Erro: formulárionão pode serenviado

Alguns camposfalharam na verificaçãode feedback sobre onão preenchimento eisso causou a confusãoem usuários que nãoconseguiam enviar enenhuma correção erapedida na tela

EspecificaçãoFuncionais

Conferir se todas as questõesestão sendo verificadas e se ofeedback para as nãopreenchidas está aparecendode modo correto em tela, comonos itens 14 e 22 do Passo 2;Conferir se durante osalvamento dados não estãosendo resetados no formulário,como no item 6.1 e 6.2 doPasso 1.

7

Erro 500

Erro que ocorriaquando o usuário

preenchia um e-mailem formato errado. Aoinvés de retornar falhano endereço o SIUtravava e na telaaparecia erro 500. Omesmo ocorria paraalgumas falhas decomunicaçãotemporária com oservidor


Checar e-mail do formulárioantes do envio (realizado);Personalizar página de Erro 500

4

CPF incorreto

Problemas no

preenchimento do CPFpor dúvidas quanto aodocumento ediferenciação do "0" aesquerda


Demonstrar formato do CPF;Incluir no e-mail de ativação onúmero de CPF informado;Verificar zero a esquerda

3

Telas estranhas

Erros que aconteciamno lançamento devidoa não terem sidotestatadas todas aspossibilidades delogin/logout/expiração/campos incorretos, etc.


Checar se existe previsão nosistema para o que fazer emcada uma de todas aspossibilidades possíveis de usodo usuário

3

Problema J avaProblemas ocorridosem navegadores quenão suportavam J ava


Informar de modo claro que énecessário o J ava;Não aceitar acessos sem o javahabilitado;Buscar outras formas deverificações e máscaras quenão utilizem Java.

3

Inconsistênciado status

Em algumas situaçõesespecíficas houve errode programação nasatualizações de statusdo usuário e elepoderia receber

mensagens defeedback erradas emalgumas páginas


Conferir mensagens e simularsituações 1



122


Campo RG

Problemas devido anão haver umapadronização de

quantidade decaracteres entre osnúmeros de RGs dediversos estados


Aumentar o máximo decaracteres e não aplicar

máscara no campo (alteraçãoefetuada nas primeiras horas delançamento do SIU)

1

Subtotal 22

Fonte: O autor.

Percebe-se que os itens com maior índice de chamados de atendimento são

relativos a pagamentos, somando 40% da amostra. Como o Passo 3 envolve

também a seleção de pacotes, que aparece com 10% da amostra, pode-se dizer que

metade de todos os chamados foram para atender resoluções desta etapa das

inscrições, mostrando que deve ser dada a atenção devida para estes aspectos em

um próximo sistema, visando diminuir os atendimentos.

As limitações do SIU (além daquelas relacionadas às etapas de inscrição)

ficaram em segundo lugar no ranking, com 16%. São itens que podem ser melhor

resolvidos visando a otimização do sistema, mas que, no entanto, não

impossibilitaram a utilização do mesmo na versão atual. A maioria dos itens listados

nesta categoria são desejáveis de ser ter no sistema, porém, demandariam um

tempo de desenvolvimento que não existia.

FIGURA 72 – Resultado compilado do atendimento ao usuário (Fonte: O autor)



123

Em terceiro aparecem empatados os atendimentos relativos a Editais e ao

Cadastro Básico, com 13% cada. Em relação ao Cadastro Básico, boa parte dos

chamados reflete uma desatenção do usuário no preenchimento do formulário, um

assunto que precisa ser tratado com o desenvolvimento de novas estratégias de

comunicação e verificação dos dados informados. Os problemas enfrentados com o

envio de e-mail necessitam maior atenção, pois o e-mail ainda é a forma mais efetiva

de contatar e atualizar o usuário sobre o andamento de sua inscrição. É necessária

uma pesquisa e adequação de política anti-spam para que o servidor adotado pelo

sistema não seja bloqueado, garantindo a entrega dos e-mails aos destinatários. J á

em relação aos Editais, de fato era aguardado um alto índice de atendimentos, poiso sistema unificado era desconhecido pela maioria dos usuários, gerando uma série

de dúvidas. Pequenos erros de especificações funcionais foram cometidos, pois esta

parte do sistema foi criada sem possuir muitos parâmetros de sucesso e fracasso

para avaliação durante o desenvolvimento. Por isso, algumas brechas não foram

imaginadas, e tiveram que ser corrigidas durante o andamento das inscrições.

Com 6% da amostra aparecem as dúvidas em geral, muitas delas que o

usuário envia ao invés de procurar o que precisa com mais atenção, e quando aorganização responde, ele já havia encontrado o que desejava. São os itens de

menor relevância, pois não costumam colocar a inscrição em risco. Para um

eventual redesign poderiam ser colocados como prioridade secundária, mas, se bem

resolvidos, podem diminuir o índice de atendimentos e aumentar a satisfação do

usuário.

Finalmente, com apenas 2%, os demais erros de sistema que não se

enquadraram no Cadastro Básico, Pacotes, Pagamentos ou Editais. O índice destesé baixo, pois geralmente os pequenos problemas eram corrigidos com rapidez. Em

momentos de lançamento de novos itens do SIU a equipe estava de prontidão em

conjunto com o programador para efetuar correções de imediato. No entanto, é

importante ressaltar que erros de sistema sempre merecem atenção especial,

visando corrigí-los nas versões beta, pois o usuário não costuma ter muita paciência

com eles.



124

FIGURA 74 – Exemplo de atendimento com usuário irritado (Fonte: O autor)

4.5 FEEDBACK DA ORGANIZAÇÃO

O SIU-N2010 para a Conde Curitiba trouxe um resultado visível. A

organização pautou escolhas em diversos momentos a partir dos dados fornecidos

pelo Banco de Dados. Todo o funcionamento do SIE e de sistemas interligados,

como as Ilhas de Interação, tinham por trás a eficiência do SIU. Mesmo com umíndice relativamente elevado de dúvidas que foram descritas no item anterior, os

usuários se demonstram satisfeitos com o sistema de inscrições. Isso pode ser

notado na avaliação do QUIS, na leitura dos e-mails, em comentários que são

recebidos pessoalmente. São muitas as ocasiões em que a organização recebeu

elogios. Estes fatores dão a impressão de “missão cumprida”, porém é sabido que

existe muito a ser aprimorado e desenvolvido em futuras versões.

Um dos pontos que mais trouxe problemas foi a baixa atenção dada aosrelatórios, essenciais para o acompanhamento do andamento das inscrições em

tempo real. Como nem todos eles foram feitos, e nenhum possuia um acabamento

adequado, os dados precisavam ser pesquisados diretamente na interface de

gerenciamento do banco de dados, e poucas pessoas possuiam capacitação técnica

para isso, ocorreu uma sobrecarga de trabalho para alguns colaboradores. O mesmo

problema aconteceu com a maioria das operações administrativas para correções de

erros em cadastros, previstas para ocorrerem em uma interface de fácil utilização eque também foram realizadas, em sua maioria, diretamente no Banco de Dados.



125

FIGURA 75 – Pesquisa de cadastros diretamente no Banco de Dados (Fonte: O autor)

FIGURA 76 – Consulta SQL para geração manual de relatórios (Fonte: O autor)

Outra falha que gerou uma série de inconvenientes foi o serviço de mailing.

Estava previsto no início do desenvolvimento um sistema para envio de e-mail paraum certo agrupamento de usuários, definido a partir de 2 ou 3 parâmetros. Poderia

ser escolhido, por exemplo: cidade = “Curitiba”; pagamento = “0”; e enviada uma

mensagem para este grupo avisando que o prazo para pagamento está acabando e

que só faltam 2 participantes para ser atingida a marca dos 800 curitibanos no N

Design. Este mecanismo teria acelerado e personalizado a comunicação. No final,

não tivemos na interface administrativa nem o serviço de mailing para envios em

massa, nem a consulta por parâmetros específicos, sendo que esta acabou sendo

realizada somente através de consulta SQL. Isso ocorreu devido a uma falha da

empresa contratada para realizar a programação do sistema.



126

O SIU enfrentou problemas com o serviço de envio de e-mail de maneira

geral. Um dos maiores índices de atendimento ao usuário foi devido aos e-mails de

ativação de cadastro que não chegavam, nem mesmo na caixa de spam. Isso

ocorreu porque não foram tomados os devidos cuidados com regras anti-spam,

adotadas pela maioria dos servidores de e-mail. Assim, eventualmente um dos

servidores bloqueava o envio de e-mail de todo o domínio do N2010, fazendo com

que todos os e-mails voltassem. Foi isso o que ocorreu mais de uma vez com o

Hotmail e Yahoo. Em certo momento, além das falhas nos envios, o servidor foi

adicionado à “lista negra”, como acontece com spammers, e nem mesmo os e-mails

administrativos internos da organização funcionaram por alguns dias. A cada

repetição de um erro desses ocorria um caos que tomava 1 a 3 dias para resolução.Em relação ao contato dos usuários com a organização facilitaria muito se

tivesse sido disponibilizado um formulário solicitando o preenchimento de CPF,

acompanhado do nome, e-mail e mensagem. Muitos e-mails analisado pediam

alterações, porém sem informar dados pessoais para localização do cadastro,

fazendo com que um chamado se prolongasse mais do que o necessário devido ao

tempo de atendimento e e-mails trocados.

Um ponto que não recebeu a atenção devida foi a apresentação e ajuda doSIU. Mais de 70% dos participantes são calouros de N Design, muitos não

participaram de nenhum outro evento, e mesmo os veteranos poderiam se confundir

no sistema, especialmente pelo fato dele ser unificado e ter retorno de informações

diretamente na interface, e não via e-mail. Faltou uma apresentação e explicação

destes atributos, que poderia ser feita de maneira breve, como uma mensagem de

boas-vindas, em um primeiro acesso do usuário após o cadastro básico, ou ainda,

através de e-mail aos recém-cadastrados.Outra dificuldade foi o cadastro dos estrangeiros. Como todo o sistema foi

baseado no número de CPF, eles não poderiam se cadastrar diretamente. O

cadastro deles seria feito em uma opção da interface administrativa que não exigisse

o preenchimento de todos os campos, através de um número de CPF fictício para

cada novo usuário. Esta interface atrasou e a situação ficou complicada quando

alguns estrangeiros solicitaram envios de editais para realizar atividades. No entanto,

se nem cadastrá-los era possível, o que dizer então dos editais, que só aparecem ao

usuário depois do preenchimento de todo cadastro. A resolução foi bastante

improvisada e felizmente eram apenas 2 dezenas de estrangeiros.



127

A seleção de pacotes por usuário foi outro item que gerou vários problemas.

Inicialmente cada usuário poderia fazer a seleção dos pacotes apenas uma vez,

sendo impossível alterar a seleção posteriormente, apenas reemitir o pagamento

com a mesma seleção de pacotes já feita. Devido a reclamações o sistema foi

alterado, possibilitando que o usuário refizesse a seleção de pacotes caso o seu

pagamento já tivesse expirado. Assim, a recomendação era que aqueles que

erraram na seleção de pacotes esperassem 5 dias sem efetuar o pagamento, para

que fosse habilitada a opção de refazer a seleção dos pacotes e do pagamento. Foi

também inserido um link para refazer a seleção dos pacotes, caso não tivesse sido

clicado no botão de emissão de pagamento. Cabe ressaltar que sempre houve o

aviso, escrito em tela, no termo de compromisso e ainda em uma janela de alerta, deque não seria possível fazer a alteração de pacotes selecionados, mesmo assim o

índice de solicitações de alteração se manteve alto durante todo o período.

O maior “remendo” no SIU foi também relativo aos pacotes. Foram recebidas

diversas ameaças de participantes que tinham errado na seleção, realizado seu

pagamento, e só depois foram perceber que necessitavam de outros pacotes, como

o alojamento, por exemplo, para viabilizar sua vinda ao evento. Isso gerou uma

campanha on-line, especialmente em redes sociais, pressionando a Conde Curitibapara que encontrasse uma solução para corrigir o erro destes usuários. Para evitar a

propaganda negativa foi planejado e implementado uma forma de geração de

pacotes avulsos para usuários com inscrição já finalizada. Como era inviável alterar

a interface por inteiro, a emissão destes pagamentos era feita manualmente pela

organização em um sistema auxiliar, o boleto era salvo em PDF e enviado para cada

solicitante. Foi criada uma nova tabela no Banco de Dados para armazenar estes

pagamentos que, uma vez confirmados, adicionavam o pacote equivalente para ousuário em questão na tabela de pacotes. Assim, o usuário já receberia o direito ao

seu pacote e os relatórios de quantidade de vendas por pacote e demais tabelas do

banco de dados não seriam corrompidas. Ao todo foram cerca de 200 solicitações de

pacotes avulsos feitas manualmente.

Em datas próximas ao fechamento de lotes, envios de edital, divulgação de

resultado de seleção e demais acontecimentos pré-divulgados, ou ainda, em datas

próximas a ocorrência de falhas de sistema, é necessário reforçar a equipe de

atendimento ao usuário. Nestas ocasiões, em alguns setores eram registrados mais

de 50 chamados em poucas horas de um mesmo dia. A política da Conde Curitiba



128

também colaborou para que ocorresse este fenômeno, pois eram divulgadas

informações sobre o andamento das inscrições com freqüência, a partir de um

ranking que tinha o objetivo de criar uma competição saudável em redes sociais. O

resultado era que os usuários acessavam mais o sistema e também enviavam

dúvidas com mais freqüência, como por exemplo, questionando a confirmação de

sua inscrição.

Para auxiliar no acompanhamento do andamento de cada lote de inscrição foi

disponibilizada uma barra de progressão na interface do SIU, que aparecia na

Página Principal e no Passo 3, sempre que o lote tivesse mais de 50% das vagas

ocupadas com pagamentos vigentes. Esta barra gerava uma espécie de “comoção

nacional” nas redes sociais e usuários mais assíduos acompanhavam o andamentovaga a vaga, para divulgar o momento exato do encerramento das vagas. Foi uma

estratégia de marketing que funcionou bem, gerando atendimentos de usuários mais

desesperados, em alguns momentos, mas principalmente, gerando publicidade

positiva e maior valorização, interesse e ocupação das vagas.

FIGURA 77 – Barra de progressão de ocupação das vagas no Lote 1 (Fonte: O autor)

Outros fatores que poderiam ser melhorados estão relacionados às

funcionalidades do sistema de inscrições que não foram pensadas há tempo de

serem implementadas. A opção on-line para emitir certificados, carta de aceite de

atividade e “ingresso” para o evento, seriam boas melhorias que facilitariam a vida

do usuário e da comissão organizadora.



129

5 CONCLUSÕES E RECOMENDAÇÕES

Com este trabalho foi registrada a maior parte do processo de criação eadministração do Sistema de Inscrições Unificado do N Design Imersão 2010, um

sistema criado por estudantes e para estudantes. Inicialmente, o objetivo era muito

mais singelo do que aquele que se desenvolveu com o decorrer do desenvolvimento

do sistema. Isto pode ser notado nas dezenas de páginas das tabelas de dados aqui

resumidas, ou ainda, no diagrama de caso de uso, que mostra um relacionamento

complexo nas rotinas internas da navegação. São detalhes como estes que tornam o

sistema mais próximo da realidade do usuário.O SIU não foi sempre desenvolvido dentro de um rigor de processo de design

fechado. Havia etapas necessárias, o usuário foi incluso, validações intermediárias

foram feitas, e inúmeras de intermediárias, várias dezenas de fato, foram lançadas já

com as inscrições em andamento. Isso confere ao projeto um aspecto de

experiencialismo. Muitos fatores aqui retratados refletem as versões mais recentes,

já com diversas correções em relação às primeiras que foram ao ar.

Parte das constantes revisões foi devido à escassa experiência da equipe, dedesigners, programadores e organizadores envolvidos. J á que não se tratava de um

sistema baseado 100% em algo existente, e que a equipe estava pela primeira vez

envolvida em um evento de grande porte, muitos fatores não foram considerados de

maneira precisa e tiveram de ser corrigidos, na medida do possível.

Alguns aspectos, que neste trabalho foram suprimidos ou apenas

brevemente apresentados, como a emissão de pacotes avulsos, ocasionaram

mudanças estruturais que foram implementadas em uma arquitetura que não previa

demandas adicionais. Isso ocasionou algumas falhas no relacionamento entre as

tabelas de dados, impossibilitando a exatidão de alguns relatórios.

Um balanço após a finalização do trabalho permite compreender de maneira

clara porque erros se repetem ano após ano em tais sistemas. Faltam registros e

pesquisas na área. A cada edição, organizadores, designers, programadores, toda a

equipe envolvida, necessita reinventar e repensar aspectos básicos. Neste sentido,

este trabalho teve o intuito de contribuir com a análise de um sistema unificado, fato

que este autor acredita ser de vasta utilidade aos organizadores, em especial, pela



130

facilidade na administração e cruzamento dos dados. Acrescenta-se que a pesquisa

e aferição de diretrizes para sistemas de inscrições podem ser de grande valia,

como continuidade das contribuições científicas na área.

Com relação à interface gráfica é necessária uma pesquisa mais

aprofundada de parâmetros válidos para sistemas similares em geral, já que no SIU

esta não foi a principal atenção dos desenvolvedores, até porque a demanda era por

um resultado que se adequasse as individualidades do N2010. Neste sentido um

caminho poderia ser a reflexão sobre características comuns, de modo a traçar uma

interface padrão para utilização e administração de sistemas de inscrição, outra

continuidade possível desta pesquisa aqui iniciada.

Uma vez que os eventos acadêmicos estão em crescimento acelerado, e que

muitos deles ainda utilizam meios precários de captação, armazenamento e

administração de dados, como foi demonstrado ao longo do projeto, o

desenvolvimento de um sistema padrão baseado em um processo de design

universal pode representar grande auxílio aos organizadores, que muitas vezes não

dispõem de recursos humanos ou financeiros para desenvolver um sistema próprio

de inscrições, mas que poderiam obter um melhor custo-benefício a partir da

utilização de um sistema terceirizado.

Após o N Design Imersão, outros eventos de grande porte como o 9º

Congresso Brasileiro de Pesquisa e Desenvolvimento em Design (P&D Design), a

Bienal Brasileira do Design 2010 e o 1º Encontro Latinoamericano de Estudantes de

Arquitetura (ELEA) utilizaram-se de conceitos do SIU-N2010 para o desenvolvimento

de seus sistemas de inscrições. Além disso, pela primeira vez nos últimos anos, a

edição subseqüente do N Design, a ser realizada em 2011 na cidade do Rio de

J aneiro, já anunciou o interesse de continuar a pesquisa associada ao SIU,

baseando o seu sistema a partir da pesquisa realizada com este projeto, assim que

este for finalizado.

Existem muitos aspectos em que a análise poderia ser aprofundada, no

entanto, ficou restrita neste trabalho ao propósito de um Trabalho de Conclusão de

Curso. Na realidade, trata-se de um sistema que pode estar em constante

desonvolvimento e análise, e, mesmo assim, sempre haverá algo a mais para serfeito, pois novas tecnologias e formas de arquivamento e tratamento de dados

surgem com freqüência.



131

Conclui-se que o projeto atingiu seus objetivos associados à análise do

Sistema de Inscrições Unificado do N Design Imersão 2010, não só apresentando

todos os aspectos fundamentais da estruturação e do desenvolvimento do sistema,

mas também a partir da compilação das pesquisas de validação e feedback dos

usuários envolvidos, apresentando assim uma contribuição consistente àqueles que

derem seqüência ao desenvolvimento científico da área e àqueles que vierem a

desenvolver novos sistemas para eventos.



132

REFERÊNCIAS

ACHOUR, M. et al. Manual do PHP. Disponível em:

<http://br3.php.net/manual/pt_BR/index.php>. Acesso em: 19/09/2010.

AGNER, L. Ergodesign e arquitetura de informação: trabalhando com o usuário.

Rio de J aneiro: Quartet. 2a. Ed, 2009.

AGNER, L.; SILVA, F. Uma introdução à disciplina de arquitetura de informação :

conceitos e discussões. Anais do 2. Congresso Internacional de Pesquisa emDesign. Rio de J aneiro: ANPED, 2003.

AGNER, L., MORAES, A. (Orientador). Arquitetura de in formação e Governo

Eletrônico: Diálogo Cidadãos-Estado na World Wide Web - Estudo de Caso e

Avaliação Ergonômica de Usabil idade de Interfaces Humano-Computador . Rio

de J aneiro, 2007, 354p. Tese de Doutorado - Departamento de Artes e Design,

Pontifícia Universidade Católica do Rio de J aneiro.

BOSCARIOLI, C. et al. Uma reflexão sobre Banco de Dados Orientados a

Objectos. Paper presented at the Congresso de Tecnologias para Gestão de Dados

e Metadados do Cone Sul, Paraná, Brasil, 2006.

BROCKMAN, R., HORTON, W., BORCK, K. From Database to hypertext via

electronic publishing: an information odyssey. In Barret, E. (ed.) The society o f text:

hypertext, hypermedia, and social construction of information . Cambridge, MA:

the MIT Press. p. 162-205.

CHAUDRI, A. B; ZICARI, R. Succeeding with Object Databases: A Practical

Look at Today's Implementations with Java and XML . 1a. Ed. Willey Computer

Publishing, 2001.

CYBIS, W. Ergonomia e Usabilidade: conhecimentos, métodos e aplicações. São

Paulo: Novatec Editora, 2007.

DERTOUZOS, M. The Unfinished Revolution: Human-centered computers and



133

what can do for us. New York: W. Computer, J . Miley & Sons. 1997.

GARRETT, J . The elements of user experience. New York: New Riders, 2003.

LÖBACH, B. Design Industrial - As Bases para a Configuração dos Produtos.

São Paulo: Edgar Blucher, 2001.

LYNCH, P., HORTON, S. Web Style Guide, 3rd edition: Basic Design Principles

for Creating Web Sites. 3a. Ed. Yale University Press, 2009. Disponível em:

<http://webstyleguide.com/wsg3/index.html> Acesso em: 19/09/2010.

MAGUIRE, M. Methods to support human-centred design. International J ournal of

Human-Computer Studies, vol 55, 2001.

MANDEL, T. The Elements of User Interface. New York: W. Computer, J . Miley &

Sons. 1997.

MAYHEW, D. Principles and Guidelines in software user interface design. New

J ersey: Prentice Hall, 1992.

MUNZLINGER, E. Tipos de sites. Material referente à disciplina de Introdução à

Tecnologia Web, 1º ano de Sistemas de Informação - 2010. Disponível em:

<http://www.elizabete.com.br/site/Ensino/Entries/2010/2/8_Tecnologia_Web_2010.ht

ml> Acesso em: 19/09/2010.

NIEDERAUER, J . Integrando PHP 5 com MySQL. 2ª Ed. São Paulo: Novatec,

2008.

NIELSEN, J . Alertbox: are users stupid? Disponível em:

<http://www.useit.com/alertbox/20010204.html>. Acesso em: 14/04/2010.

NIELSEN. J . Card Sorting: How Many Users do Test. Alertbox. 2004.

NIELSEN, J . Failure of Corporative websites. Disponível em:

<http://www.useit.com/alertbox/981018.html>. Acesso em: 14/04/2010.

ODBMS. Site do Portal ODBMS.org. Disponível em: <http://www.odbms.org>

Acesso em: 20/09/2010.



134

OLIVEIRA, D. Sistemas, organização e métodos: uma abordagem gerencial . 15.

ed. São Paulo: Atlas, 2005.

PADOVANI, S.; MOURA, D. Navegação em Hipermídia – uma abordagemcentrada no usuário. Rio de J aneiro: Moderna. 2008.

ROSENFELD, L.; MORVILLE, P. Information Architecture for the world wide web.

2nd ed. Sebastopol, CA: O'Reilly, 2002.

RUBIN, J ., CHISNELL, D. Handbook of Usability Testing: How to Plan, Design,

and Conduct Effective Tests. 2a. Ed. New York: Wiley Technical Communication

Library, J ohn Wiley & Sons, Inc. 2008.

SANTA ROSA, G., MORAES, A. Ergonomia e usabilidade em formulários

eletrônicos na internet: um estudo de caso sobre comércio eletrônico . 2005.

Dissertação (Mestrado em Artes e Design) - Pontifícia Universidade Católica do Rio

de Janeiro, Rio de J aneiro, 2005.

SHNEIDERMAN, B. Designing the user interface: strategies for effective human-

computer interation. 2a. Ed. Chicago: Addison Wesley, 1998.

TULIS, T., ALBERT, B. Measuring the user experience: collecting, analizing, ans

presenting usability metrics. Burlington: Morgan Kaufmann. 2008.

VORA, P., HELANDER, M. Hypertext and its implications for the internet. In:

HANDBOOK of human-computer interaction. Amsterdam: Elsevier, 1997.

WURMAN, R. S. Ansiedade de Informação. São Paulo: Cultura Editores

Associados, 2003.



135

APÊNDICES

APÊNDICE 01 – CAPTURA DE TELA DAS ETAPAS DE INSCRIÇÃO................136 APÊNDICE 02 – DIAGRAMA DE CASO DE USO ...............................................147 APÊNDICE 03 - QUIS – QUESTIONÁRIO DE SATISFAÇÃO DO USUÁRIO COM A

INTERFACE ..................................................................................................148 APÊNDICE 04 – COMPILAÇÃO DO RESULTADO DO QUIS – QUESTÕES

FECHADAS...................................................................................................152 APÊNDICE 05 – COMPILAÇÃO DO RESULTADO DO QUIS – QUESTÕES

ABERTAS......................................................................................................161



136

APÊNDICE 01 – CAPTURA DE TELA DAS ETAPAS DE INSCRIÇÃO

PÁGINA DO SITE DO N2010 QUE DÁ ACESSO AO SIU

PÁGINA INICIAL DO SIU



137

CADASTRO BÁSICO

TELA DE LOGIN



138

TELA DE RECUPERAÇÃO DE SENHA

PASSO 1 – DADOS BÁSICOS



139

PASSO 1 – SEÇÃO B: LOCAL/CONTATO

PASSO 1 – SEÇÃO C: FORMAÇÃO



140

PASSO 1 – SEÇÃO D: OUTROS

FINAL DO PASSO 1



141

PASSO 2 – CENSO DO ENCONTRISTA

PASSO 2 – CENSO DO ENCONTRISTA (ESCALAS DE OPOSIÇÃO SEMÂNTICA)



142

OPÇÃO DE GERAR NOVO PAGAMENTO

OPÇÃO DE REIMPRIMIR BOLETO



143

PÁGINA PRINCIPAL

PÁGINA PRINCIPAL COM CONFIRMAÇÕES PARA APROVADO EM EDITAL



144

PÁGINA PRINCIPAL COM CONFIRMAÇÃO PARA PARTICIPANTE SEM EDITAIS

PÁGINA DE AJ UDA



145

PÁGINA FALE CONOSCO

PÁGINA DE EDITAIS COM SUBMISSÕES REALIZADAS



146

EDITAIS – EXEMPLO DE EDITAL J Á INSCRITO SENDO VISUALIZADO



147

APÊNDICE 02 – DIAGRAMA DE CASO DE USO



148

APÊNDICE 03 - QUIS – Questionário

de Satisfação do Usuário com a

Interface

QUIS – Sistema de InscriçõesUnif icado SIU-N2010Questionário de Satisfação do Usuáriocom a Interface. Modelo adaptado apartir Shneideman (1997)

Este é um instrumento de pesquisa

para o Trabalho de Conclusão deCurso de Design Gráfico daUniversidade Federal do Paraná, daautoria de Alexander Czajkowski.

Para as respostas a seguir considere oSistema de Inscrições Integrado do NDesign Imersão 2010, disponível em:https://inscricoes.ndesign.org.br/

O formulário é dividido em 8 partes e o

tempo previsto para preenchimento éde cerca de 15 minutos. Suasrespostas serão enviadas apenas aofinal da 8ª parte.As perguntas indicadas por asterisco(*) são obrigatórias.

Idade*:- até 18 anos- 19 a 21 anos- 22 a 25 anos

- 26 a 29 anos- 30 anos ou mais

Gênero*:- masculino- feminino

1ª PARTE: Experiência com oSistema

1.1 Há quanto tempo você usa este

sistema?*- Menos do que uma hora- De 1 hora até menos de 1 dia

- De 1 dia até menos de 1 semana- De 1 semana até menos de 1 mês- De 1 mês até 6 meses

1.2 Aproximadamente quantasvezes você usou o s istema?*- 1 vez- 2 vezes- 3 a 5 vezes- 6 a 10 vezes- mais de 10 vezes

1.3 Aproximadamente quantasvezes você enfrentou problemascom o s istema?*

- nenhuma vez- 1 vez- 2 vezes- 3 a 5 vezes- 6 a 10 vezes- mais de 10 vezes

1.3.1 Caso tenha enfrentadoproblemas, como conseguiuresolvê-los? - os problemas não foram resolvidos- suporte via e-mail- suporte telefônico- suporte via chat- pesquisando em redes sociais (orkut,twitter, etc.)- descobri a solução na seção de ajuda- descobri a solução com amigos- resolvi com tentiva e erro- nenhuma das opções anteriores

2ª PARTE: Experiência anterior

2.1 Quantos sistemas semelhantesvocê já utilizou?* Considere outros sistemas deInscrições de eventos- nenhum- 1- 2

- 3 ou 4- 5 ou 6- mais do que 6



149

2.1.2 Caso você já tenha utilizadooutros sistemas semelhantes,comparativamente falando, comovocê classif ica o Sistema de

Inscrições do N Design 2010: Mal resolvido < 1 2 3 4 5 > BemResolvido

2.1.3 Caso você já tenha utilizadooutros sistemas semelhantes, citeexemplos que você considera bemresolvidos: Caso você não tenha utilizado outrossistemas, deixe esta questão embraço.

< aberta >

3ª PARTE: Impressões sobre autilização do sistema

3.1 Reações ao sistema*: Considere os conceitos apresentadosem cada linha como seus respectivosextremos. Terrível < 1 2 3 4 5 > MaravilhosoFrustrante < 1 2 3 4 5 > Satisfatório Tedioso < 1 2 3 4 5 > EstimulanteDifícil < 1 2 3 4 5 > FácilCapacidade inadequada < 1 2 3 4 5 >Capacidade adequadaRígido < 1 2 3 4 5 > Flexível

3.2 A respeito do s istema ser integrado, unificando todos os t iposde inscrição dentro de um evento,

você considera que esta opção é*:Considere os conceitos apresentadosem cada linha como seus respectivosextremos.Insatisfatória < 1 2 3 4 5 > SatisfatóriaIlógica < 1 2 3 4 5 > Lógica

3.3 Qual o principal ponto forte dosistema*: < aberta >

3.4 Qual o principal ponto fraco dosistema*: < aberta >

4ª PARTE: Tela

4.1 Letras na tela do computador*: Difícil leitura < 1 2 3 4 5 > Fácil leitura

4.1.1 Imagem das letras*: Desfocada < 1 2 3 4 5 > Nítida

4.1.2 Formato das letras (fontes)*: Pouco legíveis < 1 2 3 4 5 > Muitolegíveis

4.2 Realces na tela*:

Inúteis < 1 2 3 4 5 > Úteis

4.2.1 Uso de negrito*: Inúteis < 1 2 3 4 5 > Úteis

4.3 Layouts das telas facili tam*: Nunca < 1 2 3 4 5 > Sempre

4.3.1 Quantidade de informação quepode ser apresentada na tela*: Inadequada > Adequada

4.3.2 Organização da in formação natela*: Lógica < 1 2 3 4 5 > Ilógica

4.4 Sequência das telas*: Confusa < 1 2 3 4 5 > Clara

4.4.1 Próxima tela em umaseqüência*:

Imprevisível < 1 2 3 4 5 > Previsível4.4.2 Voltar para a tela anterior*: Impossível < 1 2 3 4 5 > Fácil

4.4.3 Progressão das tarefasrelativas ao trabalho*: Confusas < 1 2 3 4 5 > Claramentedefinida

4.5 Por favor escreva seus

comentários sobre o tópico “ tela” : < aberta>



150

5ª PARTE: Terminologia e Sistemade Informação

5.1 Uso da nomenclatura em todo osistema*:Inconsistente < 1 2 3 4 5 > Consistente

5.1.1 Nomenclatura relacionada acada tarefa*: Inconsistente < 1 2 3 4 5 > Consistente

5.2 A nomenclatura util izada está deacordo com a tarefa que está sendo

executada?* Nunca < 1 2 3 4 5 > Sempre

5.2.1 A nomenclatura decomputador é utilizada*: Demasiadamente < 1 2 3 4 5 >Apropriadamente

5.2.2 Nomenclatura na tela*: Ambígua < 1 2 3 4 5 > Precisa

5.3 Mensagens que aparecem natela*:Inconsistentes < 1 2 3 4 5 >Consistentes

5.3.1 Posição das inst ruções natela*:Inconsistente < 1 2 3 4 5 > Consistente

5.4 Mensagens*:

Confusas < 1 2 3 4 5 > Claras5.4.1 Instruções para comandos oufunções*: Confusas < 1 2 3 4 5 > Claras

5.4.2 Instruções para correção deerros*: Confusas < 1 2 3 4 5 > Claras

5.5 O sistema lhe mantem

informado sobre o que está sendofeito*: Nunca < 1 2 3 4 5 > Sempre

5.5.1 A Realização de uma operaçãoconduz a um resultado previsível*: Nunca < 1 2 3 4 5 > Sempre

5.5.2 Quantidade de feedback dosistema para ações efetuadas*: Escasso < 1 2 3 4 5 > Demasiado

5.5.3 Tempo de espera entre asoperações feitas*:Inaceitável < 1 2 3 4 5 > Aceitável

5.6 Mensagens de erro*: Inúteis < 1 2 3 4 5 > Úteis

5.6.1 Mensagens de erro esclarecemo prob lema*: Nunca < 1 2 3 4 5 > Sempre

5.6.2 Redação das mensagens deerro*: Desagradável < 1 2 3 4 5 > Agradável

5.7 Por favor escreva os seuscomentários sobre nomenclatura esistema de informação aqui: < aberta>

6ª PARTE: Aprendizagem

6.1 Aprendizado para operar osistema*:Difícil < 1 2 3 4 5 > Fácil

6.1.1 Início da utilização*: Difícil < 1 2 3 4 5 > Fácil

6.1.2 Aprendizado de recursosavançados*: Difícil < 1 2 3 4 5 > Fácil

6.1.3 Tempo para aprender a usar osistema*: Lento < 1 2 3 4 5 > Rápido



151

6.2 Exploração de recursos por tentativa e erro*: Desencorajada < 1 2 3 4 5 >Encorajada

6.2.1 Exploração de recursos*: Arriscada < 1 2 3 4 5 > Segura

6.2.2 Descoberta de novosrecursos*: Difícil < 1 2 3 4 5 > Fácil

6.3 Relembrar nomes e uso decomandos *:Difícil < 1 2 3 4 5 > Fácil

6.4 Tarefas podem ser executadasde uma única maneira*: Nunca < 1 2 3 4 5 > Sempre

6.4.1 Número de etapas por tarefa*:Demasiado < 1 2 3 4 5 > Apenas onecessário

6.4.2 Etapas para concluir a tarefaseguem uma sequencia lógica*: Nunca < 1 2 3 4 5 > Sempre

6.4.3 Feedback sobre a conclusãode uma sequencia de etapas*: Confuso < 1 2 3 4 5 > Claro

6.5 Por favor escreva os seuscomentários sobre aprendizadoaqui:< aberta >

7ª PARTE: Capacidades de sistema

7.1 Velocidade do sistema*: Muito lento < 1 2 3 4 5 > Rápido osuficiente

7.1.1 Tempo de resposta para amaioria das operações*:

Muito lento < 1 2 3 4 5 > Rápido osuficiente

7.2 O sistema é confiável*: Nunca < 1 2 3 4 5 > Sempre

7.2.1 Erros de sistema ocorrem*:

Frequentemente < 1 2 3 4 5 >Raramente

7.2.2 O sistema avisa sobreproblemas potenciais*: Nunca < 1 2 3 4 5 > Sempre

7.3 Corr igir os seus erros*: Difícil < 1 2 3 4 5 > Fácil

7.3.1 Corrigi r erros de digitação*:

Complexo < 1 2 3 4 5 > Simples

7.3.2 Possibilidade para desfazer ações*: Inadequada < 1 2 3 4 5 > Adequada

8ª PARTE: Considerações Finais

8.1 Este espaço é livre para vocêfazer observações em geral e/ousugerir alterações para o Sistemade Inscrições do N Design Imersão2010: < aberta >



152

APÊNDICE 04 – COMPILAÇÃO DO RESULTADO DO QUIS – QUESTÕES

FECHADAS



153



154



155



156



157



158



159



160



161

APÊNDICE 05 – COMPILAÇÃO DO RESULTADO DO QUIS – QUESTÕES

ABERTAS

usuário2.1.3 Caso você já tenha uti lizado outros sistemas semelhantes,cite exemplos que você considera bem resolvidos:

2 J a utilizei sistema de inscricoes de outros eventos, mas esse do ncuritiba foi o mais confiavel e que nao demonstrou problemas ate ondeutilizei.

3"Utilizei P&D 2008, SBGames 2008 e 2009.Não lembro direito dos sistemas, nenhum foi remarcavelmenteeficiente."

4 Nossa senhora... não lembro como eram os outros em detalhe.

5 Compra on line da Fnac e DELL6 - Sistema de Inscrição N Design 20067 "Sistema do FISL [http://softwarelivre.org/fisl11/menu/inscricoes]."

8Eu utilizei outro sistema semelhante, mas NEM de longe tão bomquanto esse.

10 não me lembro de imediato.11 Lattes, sistema de inscrição do vestibular da UFSC, IFSC e UDESC.13 Não lembro.14 o mais próximo sao formularios de envio!

20

Os sistemas utilizados anteriormente não eram tão desenvolvidos

quanto o em questão. Abrangiam apenas questões específicas enecessárias para a realização do objetivo.

usuário 3.3 Qual o principal PONTO FORTE do sistema:1 poder ter todas as informações sobre minha inscrição dentro dele.

2A integracao entre todos os elementos do encontro e a organizacao deter um unico ponto para conseguir varias informacoes importantesreferentes a pessoa e sua participacao direta dentro do encontro.

3 A centralização das informações.

4Informação. Ele possui todas as informações que eu precisei praefetuar a inscrição, assim como cada etapa e na finalização, existindo

também uma sessão (se escreve assim?) de AJ UDA.5 Facilidade de carregamento6 Escala Likert7 Sistema intuitivo. Interface clara, objetiva.

8organização das ideias, facil entendimento das funções, uso de cores eo estilo narrativo/vocabulario utilizado (é bem escrito)

9Detalhamento de cada passo e explicações utilizando vocabulárioacessível.

10A separação em "abas" das seções e os feedbacks quase "humanos"das mensagens e avisos.

11 "Para os encontristas a capacidade e praticidade de atendimento paramuitos de forma ágil.Para os organizadores uma forma mais fácil de organização de dados,



162

imagino."12 Organização.13 Fácil de acessar - link > CPF > senha.14 Segurança

15 é simples16 Flexibilidade17 Contador regressivo de vagas18 facilidade e diversidade

19As escalas de graduação no censo (as mesmas presentes aqui nestapesquisa)

20 qualidade do banco de dados que irá gerar

usuário 3.4 Qual o pr inc ipal PONTO FRACO do sistema:

1

"ele se propõe a manter uma sequência linear das etapas da inscrição,

mas na prática tem de voltar os passos para conclusão total doprocesso.

Não que isso seja ruim, ou difícil, mas a forma que ele é apresentadoquando você se depara tendo de voltar passos, pensa que pode teralgo errado acontecendo."

2 Nao encontrei nenhum ponto fraco todo esse tempo que utilizei.3 O acesso a partir do site do evento.4 A falta de dinamismo, flexibilidade e interação com o usuário.5 Não detectei6 Extenso (formulário/ censo)

7 Não há um ponto fraco que se destaque, apenas alguns itens quepodem ser melhorados.

8de boa, não achei nenhum. com meus parcos conhecimentos emusabilidade e hci

9Muitos pontos de exclamação, aproximam as informações demais a umformato hilariante, que infelizmente parece gozação em certosmomentos.

10

O maior problema que eu tive, o qual não sei se pertence de fato aosistema, é que após um período de tempo ele sai do ar, isto é, euprecisei efetuar o login novamente e as informações que eu estavapreenchendo não foram salvas.

11

"Como todo sistema apresenta possíveis falhas. Ao enviar minha fichapara inscrição como monitora, o sistema me confirmou o envio e naverdade não tinha ido.Problema de conexão talvez?"

12 Quantidade de perguntas por vezes desestimula as pessoas!

13Algumas vezes diz para marcar apenas uma opção e, ao selecionaressa única, dá erro e diz para marcar três (ou algo que o valha) edepois diz, novamente, que é para selecionar apenas uma.

14 Demora para preencher15 não lembro de nenhum

16 Extenso, tedioso.17 Tempo conectado ao sistema para inscrições de atividades18 ñ tem



163

19 Confuso na hora de salvar ou enviar os passos.20 pouco estimulante.

usuário 4.5 Por favor escreva seus comentários sobre o tópico “ tela” :

2 O layout poderia ser um pouco mais interessante e menos rigido.

4As telas poderiam ter algumas oções pra quem tem necessidadesespeciais, como baixa visão, pra mudar o contraste do fundo ou otamanho da letra (que é pequeno)... enfim.

7

"A divisão em passos é bem interessante. Entretanto, as informaçõesdo passo 1 (Dados básicos) poderiam ser divididas em 5 abas (Dadospessoais, Local/Contato, Formação, Outros e Termo deResponsabilidade). Evitaria/Diminuiria a barra de rolagem, deixando anavegação mais satisfatória.O campo que está sendo preenchido poderia ter um realce."

8

achei um sistema de uso bem simples. informações bem ordenadas.tudo claro. agora depende do usuário. a pessoa tem que dedicaratenção... não pode achar que vai fazer uma leitura dinâmica e saberde tudo. atenção e paciência na hora da leitura são essenciais.

10 Fácil assimilação e flexibilidade relativa de utilização, layout eficaz.14 nao fica muito claro depois de salvo como passar para as outras telas

usuário5.7 Por favor escreva os seus comentários sobre nomenclatura esistema de informação aqui:

4Eu não tive mensagens de erro, mas as perguntas aqui noquestionário são obrigatórias. Mas no geral o sistema de informação,

ao meu ver (como dito antes), é o ponto mais forte do sistema.

7

"*ErrosO sistema dispara mensagens de erro, como a exigência dos camposobrigatórios.Mas não em casos específicos. Por exemplo, em camposque aceitam apenas números, ele realmente não deixa digitar letras.Entretanto, não renderiza (informa) a ação errada que o usuário estáexecutando. Isso é só um detalhe sem tanto impacto, considerandoque há orientações em relação ao preenchimento.

*Mensagem que apareceSe você estiver num segundo acesso, alterando alguma informação e

clicar em Enviar, a mensagem exibida é a mesma da primeira vez [""...Alguns dados não poderão ser modificados a partir do envio""].Essa mensagem já não corresponde à situação atual do usuário. Issotambém é só um detalhe, mais uma vez, que não compromete afunção."

9Idem em relação ao uso de pontos de exclamação - causam umaimpressão de gozação em certos momentos.

10Creio que a nomenclatura apresenta uma arbitrariedade para aquelesque não estão "por dentro" da linguagem estabelecida pelo próprioevento, embora não seja algo comprometedor.

14 acho que esta de acordo!



164

usuário 6.5 Por favor escreva os seus comentários sobre aprendizadoaqui:

4

"Como fiz minha inscrição há muito tempo atrás, não lembro de muitosdos detalhes questionados. Mas de forma geral o sistema é fácil de

ser utilizado, tendo seu tempo de aprendizagem curto (no entando souuma usuária avançada deste tipo de recurso).

*Algumas perguntas não ficaram muito claras, como ""aprendizado derecursos avançados"" e ""Início da utilização""."

10Embora o sistema abra espaço para equívocos por parte de seususuários, o aprendizado é rápido e sua interface é facilmentefamiliarizada.

14 a partir do passo 2 o sistema é logico!

usuário8.1 Este espaço é livre para você fazer observações em geral e/ousugerir alterações para o Sistema de Inscr ições do N DesignImersão 2010:

2

"cara o sistema de vcs eh muito bom e deve ser referencia para osproximos encontros! tipo vender/dar/alugar para as proximascordes/condes e tudo mais.

nao canso de parabenizar vcs! D:"

3

"O link de acesso ao sistema no site do evento pode ser mais claro. Obanner é algo automaticamente ignorado por boa parte dos usuários.Mais de uma vez que acessei o site tive que perguntar onde poderia

entrar no sistema, uma vez que simplesmente desprezei o banner.As informações no bloco esquerdo da interface estão muito distante, oagrupamento poderia ser mais efetivo e me sentiria mais confortávelcom esse bloco de informações posicionado à direita do site.Bons trabalhos! =}"

4

"Problemas/ Erros encontrados:- Atualmente, se o texto for longo, se perde espaço abaixo da colunada esquerda;- Os editais já foram fechados, mas continuam em aberto no sistema(mesmo que seja apenas pra download do PDF). Em prazo, ao invésda data, deveria ter algo como ""INSCRIÇÃO ENCERRADA"";

- Quando clicquei em FALE CONOSCO o sistema voltou para a páginade login (isso aconteceu apenas uma vez);- Fui ao ""Dados Completos"" e modifiquei um detalhe (é pra estar emaberto ainda isso?). Ao finalizar e SALVAR, o sistema me disse pralembrar de ENVIAR. Fui lá novamente e apertei ENVIAR (ao invés deSALVAR) e a mensagem foi: ""Dados de usuário enviados. Agora vocêpode preencher o passo 2 (censo)."" No entanto essa opção não estámais válida pra mim (por já ter feito a inscrição completa).

Sugestões:- Diminuir a verticalidade das informações na página (barra de rolagem

muito longa);- Os botões ""Página principal"" e ""ajuda"" poderiam estar com umaaparência mais aproximada a um botão (sombreamendo maior talvez



165

ajudasse), inclusive mostrando o clicar do botão per si (em Editais tb);- Em Editais, quem está inscrito em uma atividade X, poderia ter umatela diferenciada e ver a atividade (incluir na barra principal daesquerda seria interessante tb) e informações relevantes relacionadas

com a atividade inscrita.- A mensagem ""Tudo certo! Pagamento confirmado. Te esperamos noN!"" em vermelho dá a primeira impressão que tem algo errado (pelaassociação que temos com a cor vermelha ser algo negativo ouproblemático). Então acho que as mensagens que não fossem de erro(e informações em geral) deveriam estar em outra cor. Não há umacoerência informacional no uso da cor das fontes do sistema de formageral.

7

O sistema do N2010 atende muito bem ao que se propõe fazer. Éintuitivo, não frustra o usuário. Há alguns itens que podem sermelhorados (como pequenos detalhes descritos em etapas anteriores

desta pesquisa). E algumas facilidades que podem serdisponibilizadas, como o serviço de auto completar o endereço atravésdo cep, para o usuário em versões posteriores.

8 Só tenho elogios. Muito bom MESMO!9 Nada é perfeito, mas foi tudo bem feito.

Seria muito difícil permitir aos instrutores de atividades (mergulhos,sepa's, etc) alterarem suas atividades diretamente no sistema?Atualmente é necessário fazer uma solicitação por email sendo

Documents

Sistema de Inscrições TCC-AlexanderCzajkowski-SIU-N2010