TACATICAWEB Construção de uma Plataforma Digital para a Gestão da Naumteria UNIVERSIDADE ESTADUAL PAULISTA “JÚLIO DE MESQUITA FILHO” Faculdade de Arquitetura, Artes, Comunicação e Design - FAAC Departamento de Design Projeto de Conclusão de Curso Rafaela Galhego da Silva Orientação: Profa. Dra. Ana Beatriz Pereira de Andrade Coorientação: Prof. Me. Guilherme Cardoso Contini Bauru, 2023 TACATICAWEB Construção de uma Plataforma Digital para a Gestão da Naumteria S586t Silva, Rafaela Galhego da Tacaticaweb : construção de uma plataforma digital para a gestão da Naumteria / Rafaela Galhego da Silva. -- Bauru, 2023 60 p. Trabalho de conclusão de curso (Bacharelado - Design) - Universidade Estadual Paulista (Unesp), Faculdade de Arquitetura, Artes, Comunicação e Design, Bauru Orientadora: Ana Beatriz Pereira de Andrade Coorientador: Guilherme Cardoso Contini 1. Design. 2. Naumteria. 3. Gerenciamento da informação. 4. Social networking Web sites. I. Título. Sistema de geração automática de fichas catalográficas da Unesp. Biblioteca da Faculdade de Arquitetura, Artes, Comunicação e Design, Bauru. Dados fornecidos pelo autor(a). Essa ficha não pode ser modificada. 4 SU M ÁR IO 4 Glossário 5 Resumo 6 Introdução 7 Fundamentação 8 Contexto 10 Definição do Problema 12 Pesquisa com Público 20 Web e Mobile-First 22 Usabilidade 25 Web App 27 A Proposta 31 Desenvolvimento 32 Identidade Visual 38 Sketches 39 Sitemap 41 Wireframes 43 Protótipo 46 Fase de Testes 55 Considerações Finais 56 Agradecimentos 57 Referências 5 GL OS SÁ RI O Aplicação Nativa: aplicativo desenvolvido para um dispositivo ou plataforma específica. Breque: neste contexto, são variações no samba, que podem ter diferentes níveis de complexidade. CSS: é um mecanismo utilizado para aplicar o layout a uma página Web. Define parâmetros como cores, formatos, tamanhos, entre outros. Desktop: computador de mesa, utilizado em um único lugar. Escolinha: como é chamado o período de aprendizado dos novos ritmistas, onde aprendem desde o básico sobre seu instrumento. HTML: linguagem de marcação utilizada na construção de páginas na Web. Lei Murilo: é uma regra interna da Naumteria, através da qual um ritmista pode justificar sua ausência em ensaios que contam presença. Leitores de tela: sistema que realiza a leitura e identificação de conteúdos, transmitindo para áudio as informações visuais na tela. Manifesto (de Web App): é um arquivo que fornece informações sobre o aplicativo. Mobile-first: refere-se à criação de páginas pensadas primeiro para dispositivos móveis. Naipe: como são chamados cada grupo ou categoria de instrumentos. Reuniões Gerais: aqui, são reuniões para todos os membros, nas quais são debatidas e decididas pautas que regem o funcionamento da Naumteria. Ritmista: neste contexto, refere-se aos alunos da Unesp Campus de Bauru que fazem parte da Naumteria. Service worker: é uma ferramenta que pode controlar páginas de um site, modificando sua navegação. Sitemap: esquema que lista todas as páginas e as relações entre elas. URL: endereço de rede de um arquivo digital. Web App: é um site que pode ser instalado e assim se comportar como aplicativo. Wireframe: protótipo para entender onde ficam os elementos, seus tamanhos, tudo ainda sem muita personalização, apenas para entender a disposição das informações. 6 RE SU M O TacaticaWeb é uma proposta de produção de site para a Bateria Universitária da Unesp de Bauru, a Naumteria. Foi pensado levando em consideração suas necessidades e particularidades com relação às funções e definições de usabilidade do sistema, identificadas através de pesquisas com o público-alvo. Este estudo aborda as preferências dos usuários e as relaciona com as possibilidades de desenvolvimento, utilizando ferramentas de Design na resolução de problemas, criação da comunicação visual e UX, e conceitos da Tecnologia da Informação, tais como particularidades do desenvolvimento Web e planejamento mobile- first, a fim de fazer esta conexão. Ainda como protótipo, esta proposta é capaz de avaliar a aceitação do sistema a ser desenvolvido, por meio dos testes de usabilidade aplicados, e servirá como um norte quando este for finalizado e implementado. Palavras-chave: Design, Naumteria, gerenciamento da informação, redes sociais 7 AB ST RA CT TacaticaWeb its a website production proposal to the musical group Naumteria, from Unesp Bauru. It was designed observing their needs about the functions and definitions of system usabilty, identified through target audience research. This study approaches the users preference and relates them with the development possibilities, using Design strategies in the problem solving, visual media and UX creations, and Information Technology concepts, such as peculiarities of web development and mobile-first planning, in order to create this connection. This proposal still is a prototype, capable of evaluating the acceptance of the system to be developed, through usability tests, and will work as a guide when the project is finalized and implemented. Key words: Design, Naumteria, information management, social networking Web sites 8 IN TR OD UÇ ÃO Sempre que for contar a alguém como foi estudar na Unesp, vou precisar mencionar a participação na Naumteria. Foi o projeto no qual mais me envolvi, dediquei meu tempo, me diverti, criei laços e cresci como pessoa. Eu nunca tive certeza de qual área do Design iria me dedicar, então usar esse parâmetro para definir o tema do Projeto de Conclusão de Curso, não funcionou. Mas, ao relacionar este projeto à Bateria, tudo ficou muito mais fácil e natural. Inclusive, tive 3 ideias mais estruturadas de possíveis temas e todas as três neste mesmo assunto, sendo cada uma em uma vertente completamente diferente do Design. Finalmente, a solução que fez mais sentido foi aliar os conhecimentos da graduação às experiências do Curso Técnico em Informática, realizado durante o ensino médio no Colégio Técnico da Unesp de Bauru, o CTI. Na Naumteria, sempre me interessei em atuar na parte administrativa. A instituição é gerida apenas pelos próprios ritmistas, divididos em diretorias e comissões, e logo no meu segundo semestre, comecei a me envolver mais nesse lado, que vai muito além dos ensaios entre os períodos de aula. Aqui neste projeto, utilizei um dos temas recorrentes nas reuniões internas da Naumteria - um problema de gestão de mídias discutido eventualmente, cujas conclusões recentes não têm sido definitivas -, propondo uma nova estratégia como tentativa de solucionar esta questão. Fundamentação 10 CONTEXTO A Naumteria é a Bateria Universitária de sede na Unesp de Bauru, composta por alunos deste mesmo campus, todos considerados membros ou ingressantes e ritmistas. Tem por objetivo a participação em jogos universitários como bateria de torcida, em competições de baterias universitárias, apresentações de eventos sob contratações, além da promoção e participação de ações sociais junto às comunidades locais e regionais. No início de cada ano letivo, é aberta a Escolinha. São aceitos alunos de todos os cursos da Unesp de Bauru, sem restrições e sem necessidade de conhecimentos musicais prévios. Ao entrar na Naumteria, o ingressante pode escolher de acordo com sua vontade e identificação qual instrumento vai tocar (se o mesmo tiver aberto vagas), definindo assim, o naipe do qual fará parte. Após um semestre participando da Escolinha, este ingressante se torna oficialmente membro e pode inclusive se inscrever para as Diretorias Administrativas e Comissões, fazer parte de Reuniões Gerais, nas quais são tomadas as decisões que definem o funcionamento da Naumteria, passa a ter seu registro de presença contabilizado, bem como adquire todas as demais responsabilidades de um membro ativo na Bateria. A Naumteria é organizada de maneira horizontal, com as funções divididas entre Diretorias Administrativas, Diretorias de Naipe e Comissões Temporárias, resumidamente seguindo hoje esta configuração: Diretorias Administrativas: Ação Social é responsável por fazer contato com instituições da cidade e do câmpus a fim de proporcionar e organizar as atividades sociais das quais a Bateria participa. Comunicação administra as redes sociais da Naumteria. Faz posicionamentos oficiais quando necessário, interação com o público e divulgações de atividades da Bateria. Eventos responde pelas contratações da Naumteria como atração, desde o contato e negociação com o contratante até a apuração de disponibilidade dos ritmistas e garantia de realização do compromisso por ambas as partes, contratante e contratada. 11 Externos mantém o bom relacionamento com as instituições parceiras dentro do campus, realiza reserva de locais de ensaio e demais demandas necessárias junto à Administração Geral da Unesp de Bauru. Recursos controla e registra o fluxo de caixa da Bateria, realiza e recebe pagamentos, avalia a possibilidade de novos gastos quando necessário, sempre visando o bom funcionamento da gestão. Gestão de Pessoas (GP) busca garantir o bem-estar e a boa relação entre os membros da Naumteria, trabalha a comunicação e organização interna, agenda e media reuniões mensais gerais e administrativas, atualiza os grupos internos de membros, gere conflitos, controla o registro das presenças nos ensaios e reuniões e fornece feedbacks comportamentais aos membros quando solicitado e/ou necessário. Patrimônio cuida do patrimônio da Bateria, como instrumentos, equipamentos e acessórios. É responsável pela aquisição, recebimento, disponibilização, empréstimo e também venda, doação ou descarte de cada um desses itens. Produtos projeta artigos comercializáveis ou internos com a marca da Naumteria. Realiza o desenvolvimento da arte, pesquisa de clientes, contato com fornecedores e intermediários, controle de pedidos e vendas. Diretorias de Naipe: São elas: mestre, agogô, ganzá, tamborim, caixa, ripa, surdo e harmonia. Responsáveis por agendar e ministrar ensaios, criar novos arranjos e composições, gravar e disponibilizar vídeos tutoriais do seu instrumento, ensinar aos demais membros, definir os participantes das apresentações, competições e demais eventos que a Bateria se compromete, além de fazer repasses de informações, quando necessário, aos seus ritmistas. Comissões Temporárias: Realizam todas as atividades que não estão incluídas no escopo de nenhuma diretoria. Elas são voltadas a uma tarefa específica cada, e têm como duração o período da mesma, com participação voluntária pelos membros da Bateria. 12 DEFINIÇÃO DO PROBLEMA Mensalmente são realizadas as Reuniões Gerais, para debater pautas, as quais podem ser incluídas previamente por todos os membros. Ao longo desses quase 6 anos fazendo parte desta instituição, percebi a existência de assuntos que se repetem de tempos em tempos. Alguns pelo contexto, como explicação aos ingressantes do funcionamento da Naumteria e o que já aconteceu até aqui. Outros, entretanto, acabam voltando após um problema - já debatido e não resolvido - ser identificado por outra pessoa. Um deles é a organização dos conteúdos de vídeo. Atualmente eles são armazenados pelo Google Drive, porém, devido à grande quantidade de materiais, acabou ficando desorganizado, e por ser uma plataforma de uso esporádico para alguns, ficou também desatualizado ao compartilharmos conteúdos algumas vezes somente através de grupos em redes sociais. Nem sempre foi desta forma. Era muito comum o uso de um grupo do Facebook para compartilhar os materiais, porém após o período de pandemia, viu-se uma mudança no hábito de uso desta rede pelo público da Unesp Bauru. Antes da pandemia, até o começo de 2020, era frequente a utilização de ferramentas do Facebook, como grupos e eventos, por parte de diversos projetos e comissões dentro do Campus. Após este período, quando as aulas e atividades retornaram ao 13 presencial em 2022, viu-se uma preferência muito maior pelo uso do WhatsApp e Instagram, e a divulgação de conteúdos dos projetos de extensão e instituições da Unesp Bauru em redes sociais passou a acontecer quase exclusivamente por estes meios. Nas discussões desta pauta de mídias em reunião, foi levantada a possibilidade de retomar o uso do grupo de Facebook, utilizar novas formas de armazenamento em nuvem ou diferentes plataformas existentes a fim de cumprir a função, mas após ponderações e testes nenhuma opção teve resultado satisfatório. O grupo de membros no Facebook não apenas armazenava os vídeos, mas também nele eram divulgados informes e enquetes por parte das diretorias, eventualmente realizadas discussões, entre outras funções. Pensando nisso, vi a possibilidade de ampliar minha abordagem do problema, e não apenas resolver a questão dos vídeos, como também idealizar um espaço maior de interação e organização das informações. 14 PESQUISA COM PÚBLICO Com objetivo de entender mais sobre o público-alvo, foi aplicado um questionário e realizada uma entrevista. Questionário: As perguntas foram divididas entre preferências de usabilidade de sistemas digitais e contexto da Naumteria, abordando experiências pessoais de cada um e opiniões a respeito da organização interna e distribuição de informações. Esta última categoria somente era apresentada aos entrevistados que fazem ou fizeram parte da instituição. * Indica uma pergunta obrigatória. Figura 01. Abertura do questionário aplicado. Acervo pessoal. 15 1. Quais suas preferências para sites e aplicativos de forma geral?* (opções para cada tópico: não me agrada / tenho pouco interesse / sem preferência / tenho interesse / é essencial) - uso de diversas cores e elementos - explicações detalhadas - cores claras/modo claro - cores escuras/modo escuro - aparência minimalista - conteúdo estático - pouco/nenhum texto e explicações - conteúdo em áudio/vídeo 2. Quais são seus sites/aplicativos favoritos e por quê?* 3. Se quiser dar mais alguma opinião de usabilidade ou estética que não consta anteriormente, pode acrescentar aqui Um pouco mais sobre o projeto A plataforma digital a ser desenvolvida tem o objetivo de ser uma opção para facilitar a gestão interna da Naumteria, bateria universitária da Unesp de Bauru. 4. Você é/foi membro da Naumteria?* 16 O intuito é proporcionar na plataforma uma comunicação entre membros, diretorias administrativas, diretorias de naipe e comissões, além da organização de conteúdos audiovisuais, documentos e informações sobre a história e funcionamento da bateria de forma geral 5. Qual seu ano de ingresso na Naumteria?* 6. Você já participou de alguma das diretorias administrativas?* 7. Você já participou de alguma das diretorias de naipe?* 8. Você já participou de alguma das comissões temporárias da bateria? (ônibus, festas, freelas, entre outras)* 9. Quais funções você considera essenciais em um site/aplicativo para organização interna da Naumteria?* 10. Além destas, existem funções extras você gostaria que estivessem presentes? 11. Você prefere que esta plataforma seja um site ou um aplicativo?* Agora, responda levando em consideração estas possíveis funções da plataforma 12. Se um site/aplicativo possui tutorial ou orientações, você costuma utilizá-las nos primeiros acessos?* 13. Que tipo de dispositivo você mais usaria para acessar este site/aplicativo?* 14. Qual o sistema do seu dispositivo? 15. Adicione aqui seus comentários, dúvidas ou sugestões, se desejar 17 Ao todo obtive 9 respostas, sendo 8 delas de membros ou ex-membros da Naumteria com ano de ingresso entre 2017 e 2022, uma boa representação do público-alvo. Sobre as preferências para sites e aplicativos, pude perceber pelos gráficos a seguir que o público do questionário demonstra aceitação e interesse pelo uso de cores, ainda que alguns prefiram aparência minimalista com poucos elementos. Há um desejo pela disponibilidade de um modo de cores escuras no sistema e um desagrado pela possibilidade de haver pouco ou nenhum texto de apoio, é preferível a utilização de explicações mais detalhadas. O público também é favorável à presença de conteúdos em áudio ou vídeo, mas não têm rejeição ao conteúdo apresentado de forma estática também. Figuras 02 e 03. Gráficos de preferências para sites e aplicativos. Acervo pessoal. 18 Em resposta à pergunta aberta sobre os sites favoritos e os motivos dessa preferência, os entrevistados apontaram diversos, mas a categoria mais frequente foi de redes sociais e plataformas de vídeo, como exemplo Twitter, Instagram, Tiktok, Youtube, Netflix, Twitch e Pinterest. Os demais indicados são sites de lojas (Apple e Shopee), plataformas para leitura (iDinheiro, Nyah, Fiction+) e alguns outros que não estão em nenhuma destas categorias - aplicativo do Nubank e os sites Rock Content University, Azos - Seguro de Vida, e Zoológico SP. Os motivos de tais preferências estão muito relacionados a familiaridade com o conteúdo que a plataforma aborda, mas além disso também são apontados sobre alguns a organização e facilidade de encontrar os conteúdos, elogios à navegação em outros casos e ausência de publicidades. Os entrevistados consideram importante quando uma plataforma possui um mapa para facilitar a navegação, a acessibilidade é mencionada mais de uma vez, o layout adaptado aos diferentes tipos de telas e sobre a escolha de cores é mencionada uma preferência por tons terrosos. Com base nestas respostas, vejo possibilidades de referências para diversas funcionalidades do sistema, dada a diversidade de plataformas indicadas. Então, ainda que nem todas sejam utilizadas neste momento, poderão ser revisitadas para outras implementações. A respeito das perguntas sobre a Naumteria, notei que os entrevistados são principalmente pessoas muito ativas na bateria, parte de diretorias e comissões. Apesar de não ter uma vasta quantidade de respostas ao formulário, elas são muito significativas qualitativamente por conta desta característica. Seguem os gráficos que identificam estes participantes: 19 Figuras 04. Gráfico de participação em Diretorias Administrativas. Acervo pessoal. Figuras 05. Gráfico de participação em Diretorias de Naipe. Acervo pessoal. Figuras 06. Gráfico de participação em Comissões Temporárias. Acervo pessoal. 20 Entre as funções consideradas essenciais, foram levantadas: E além destas, também foram elencadas funções que seria interessante existirem: Existe uma preferência dividida entre a plataforma ser um site ou um aplicativo, exatamente metade a favor de cada uma das opções. Por fim, 75% dos entrevistados também demonstraram interesse na existência de um tutorial nos primeiros acessos, quase 87,5% indicaram que usariam a plataforma através de smartphones, sendo principalmente utilizados com sistema Android e uma parcela significativa, de 29%, com sistema iOS. • controle de membros • páginas direcionadas às funções de cada naipe, gestão ou diretoria • portfólio com vídeos de competições e shows, descrição das premiações já conquistadas pela Naumteria • agenda compartilhada e individual - integrando as Diretorias Administrativas mas podendo ser dividida por naipes • galeria para as fotos em eventos • sistema de registro das presenças em ensaio • acervo de vídeos com divisão por breques, naipes e outras categorias através de etiquetas para cada vídeo • possibilidade de realizar formulários e enquetes na plataforma • feed de publicações • barra de busca • formulário de contato para contratações • espaço voltado à venda de produtos com a marca Naumteria • rede social interna, com perfis pessoais, interações entre membros, algo mais descontraído e não estritamente organizacional • spotted e match entre membros antes de eventos 21 Entrevista: A entrevista aconteceu de forma semiaberta, onde o roteiro de perguntas guiou a conversa, mas não restringindo o assunto. Realizei apenas uma entrevista, com uma pessoa que ingressou em 2019 e já fez parte tanto de Diretorias Administrativas (GP e Eventos), como Diretoria de Naipe (Surdo) e Comissões Temporárias (Festa), para ter uma visão nova e mais completa de como é fazer parte deste lado administrativo da Bateria. Iniciamos com uma conversa que abordou o ingresso na Naumteria, como foi o aprendizado musical e o entendimento do funcionamento da instituição. Tudo se deu de forma muito simples e rápida, visto que ela já tinha amigos que faziam parte da instituição e foi convidada muito cedo para participar de competições. O aprendizado musical foi principalmente por meio da observação de outros ritmistas, por conta desse contexto de competir tão logo, nem tudo era explicado passo a passo. A experiência de ingressar nas Diretorias Administrativas e Comissões e como se deu a gestão e organização em cada uma delas foi muito relacionada aos interesses e habilidades pessoais e desenvolvidas no curso de graduação em Relações Públicas. Algumas destas tiveram um repasse ou acompanhamento inicial por membros mais antigos, mas foi necessário também reformular para entender a melhor forma de gerir em cada momento da Naumteria, sabendo o que a Bateria precisava e o que fazia ou não sentido. O repasse das informações a uma nova gestão foi muito relacionado ao modo como aprendeu, mas adaptado aos novos moldes da Naumteria atual. Por exemplo: quando ingressou na diretoria de Eventos, os formulários para verificar disponibilidade de ritmistas para uma apresentação eram divulgados no grupo do Facebook, mas, após a pandemia, este grupo não era mais utilizado cotidianamente. Tudo passou a ser divulgado nos grupos de WhatsApp, inclusive esta verificação de disponibilidades. Sempre conciliando conhecimentos de como as atividades eram feitas e como adaptá-las às novas pessoas, mas variando conforme as demandas específicas de cada diretoria. Após a coleta de dados do público-alvo, todo o material foi organizado e levado em consideração no momento de definir os padrões a serem seguidos, juntamente com as questões técnicas essenciais no desenvolvimento de uma plataforma. 22 Com o objetivo do sistema ser de uso cotidiano, é importante focar na praticidade de acesso pelos usuários. Como o questionário demonstra, a maioria dos entrevistados utiliza smartphones, e o padrão não se restringe a este grupo ouvido na pesquisa. No livro A Web Mobile: Design Responsivo e além para uma Web adaptada ao mundo mobile, o autor Sérgio Lopes menciona os termos ‘cultura mobile-first’ e ‘pessoas mobile-first’, utilizados ao representar como cada vez mais pessoas acessam a Web e ferramentas digitais a partir de dispositivos móveis, e até o termo ‘mobile-only’ sobre pessoas que não utilizam aparelhos Desktop, apenas tablet e/ou smartphone. Segundo números do relatório Worldwide Quarterly PC Tracker da International Data Corporation (IDC), as vendas de smartphones ultrapassaram as vendas de computadores pela primeira vez no ano de 2010, dois anos antes do estimado pela empresa Morgan Stanley. E o número de dispositivos móveis apenas cresce desde então, como informado pelo Comitê Gestor da Internet no Brasil (CGI.Br), a parcela de brasileiros que possuem telefone celular próprio aumentou de 85% em 2019 para 89% em 2021, e 85% dos indivíduos com 10 anos ou mais acessaram a Internet pelo telefone celular no ano de 2021. Neste cenário, e não apenas com o projeto em questão, o desenvolvimento voltado aos dispositivos móveis é o mais adequado atualmente, sem excluir, no entanto, as demais formas de acesso à Web. Mas é importante considerar as diferenças de usabilidade nas diferentes plataformas. Quando se navega online utilizando telas pequenas, é desejável um layout mais focado, páginas simples e diretas, assim como diz Lopes (2014), a chave é a priorização de conteúdo. Descobrir quais informações realmente importam e remover o excesso. Não basta apenas diminuir o design da versão Desktop, precisa ser repensada a disposição das páginas e suas funcionalidades. E ao final, obtendo uma versão otimizada do site, oferecê-lo também aos usuários de dispositivos maiores, entregando a mesma informação de forma acessível e prática a todos, afinal é difícil especular com precisão o contexto e generalizar que o usuário mobile está sempre com pressa e o usuário desktop tem tempo para analisar páginas complexas. WEB E MOBILE-FIRST 23 Nem sempre todos têm acesso a diferentes dispositivos e facilidade com as mesmas plataformas. Portanto, ambos precisam ter acesso a todo o conteúdo, sem cortar funções do mobile nem complexificar o desktop. Além disso, também não faz sentido na usabilidade e acessibilidade a criação de telas repletas de informações, apesar do Desktop possuir esta capacidade. Vista a impossibilidade de exibir a mesma versão de um site nos mais diversos aparelhos, o ponto de partida mais fácil é considerar as restrições dos dispositivos móveis e, posteriormente, adaptar a versão final. Isso tanto pode ser obtido através de sites diferentes para mobile e Desktop, como através de um design responsivo a fim de se adaptar ao cliente, com páginas que apresentam sempre a melhor versão para a experiência do usuário de acordo com o tamanho de sua tela - ou da sua janela, no caso de computadores. O foco é o usuário ter acesso ao layout mais adequado para si. Entre estas opções, o design responsivo é a mais inclusiva, ao se adaptar a cada tipo de tela, além de ser a recomendação oficial do Google a desenvolvedores, por ser o padrão mais fácil de implementar e manter, através de um mesmo código HTML exibido no mesmo URL. O design responsivo é uma garantia de que o site seja tão flexível e adaptável quanto a Web é. Essa adaptabilidade é amplamente defendida por John Allsopp, em seu artigo A Dao of Web Design: a criação de páginas acessíveis, independentemente do navegador, plataforma ou tela a qual o leitor escolher ou precisar utilizar, ainda mencionando possíveis impressões, acesso por leitor de tela ou navegadores Braille e pensando também em uma pessoa com baixa visão que necessite fontes com tamanhos maiores. A usabilidade também diz muito sobre a acessibilidade, é necessário os sites serem otimizados possibilitando acesso de todos os usuários. Um design responsivo mobile-first obriga a focar e priorizar o conteúdo, além de, a nível de código, melhorar a performance de forma geral, considerando a capacidade reduzida de um celular em comparação a um computador - como rede móvel variável, processamento e memória reduzidos e consumo de bateria. Quando o mesmo site for executado em um Desktop ele será ainda mais rápido. 24 USABILIDADE A respeito da usabilidade, o principal conceito que tive em mente foi descrito por Steve Krug como sua primeira lei de usabilidade: “Não me faça pensar!”, no seu livro de mesmo nome. Ela determina se um projeto Web funciona ou não: se a página por si só é evidente e autoexplicativa. Sempre eliminando as possíveis perguntas do usuário ao abrir um novo site, como “por onde devo começar?” ou “isso é uma imagem ou uma opção clicável?”. Ele toma como fato que as pessoas não passam tanto tempo quando os desenvolvedores gostariam, analisando uma página. Elas normalmente têm pressa de encontrar o conteúdo necessário, procurando termos e palavras-chave relacionadas, sem ler tudo. Apenas é vista uma fração das informações na tela. E caso o usuário siga por um caminho errado, é só voltar algumas telas e reiniciar sua busca. Não existe uma grande punição por tentar adivinhar como as páginas funcionam ao invés de analisá-las calmamente. Mas além de deixar uma página com as informações descritas de forma clara o suficiente para o entendimento de um usuário com pressa, é necessário fazer uma página bem pensada com objetivo de que eles realmente entendam. Desta forma, a chance do usuário fazer uso correto é maior, assim como a sua possibilidade de retorno. É melhor para a pessoa, que consegue realizar seu objetivo na plataforma e conhecer mais sobre o sistema e tudo que ele oferece, além da única função buscada inicialmente. Ao pensar no usuário, Krug descreve cinco pontos importantes na experiência com páginas Web: • Definir uma hierarquia visual clara a cada página: o usuário precisa observar e entender, só pela aparência, o que é mais importante, quais tópicos têm a mesma importância, quais seções são partes de um mesmo assunto. E isso é feito através das escolhas de design, definindo padrões de layout específicos a cada relação de importância. • Aproveitar as convenções: existem algumas ferramentas e abordagens já consideradas convenções, de tão frequentemente utilizadas na Web, como por exemplo a existência de barra de busca e carrinho de compras. Eles funcionam praticamente da mesma forma na maioria dos sites. É um modelo funcional e recorrente, assim se torna fácil de ser compreendido. Para abrir mão de uma convenção, é 25 necessário que a nova ferramenta seja suficientemente autoexplicativa e apresente uma vantagem sobre o modelo anterior, assim justificando o aprendizado do usuário. É muito importante também usar as convenções no momento de definir o funcionamento da navegação. • Fazer uma divisão adequada das páginas ajuda o usuário a relacionar os conteúdos e encontrar o que busca. Caso uma seção não esteja relacionada ao assunto, ele pode ignorá-la, ciente de não precisar utilizar aquela área neste momento. • Deixar óbvio o que precisa ser clicado não só elimina perguntas do usuário, mas também facilita a navegação, deixando o caminho mais intuitivo. • Diminuir a confusão é essencial a fim de deixar as páginas mais claras, principalmente utilizando abordagem mobile-first, onde existe pouco espaço para transmitir as informações. Uma forma de diminuir a confusão é, sempre que possível, manter as páginas familiares e com aparência relacionada entre si, assim o usuário sabe que não foi redirecionado para outro site. A segunda lei de usabilidade de Krug diz: “Não importa quantas vezes eu tenha que clicar, desde que cada clique seja uma escolha óbvia e não ambígua”. Apesar de existirem limites no número de páginas que o usuário tem paciência de percorrer, se o mesmo entender porque precisa fazer este caminho, é válido reduzir as opções que o façam pensar a cada página se elas estiverem claras e organizadas. Por fim, a terceira lei de usabilidade de Krug, “Livre- se de metade das palavras de cada página e depois de metade das que restaram”. Ele mesmo explica sobre como não é literal, mas sim essencial ao reduzir a confusão em cada página, destacar os conteúdos mais relevantes e deixar as páginas menores. Se uma página utilizar padrões e convenções, se torna mais autoexplicativa e reduz sua necessidade de instruções. Ao buscar este conteúdo para ter um entendimento maior de usabilidade, acabei me deparando com algumas questões de acessibilidade nas quais eu não havia pensado inicialmente e decidi implementar também. 26 A primeira delas, que até seria feita, porém de forma inconsciente, é sobre como melhorar a usabilidade das pessoas sem deficiência, torna as plataformas um pouco mais acessíveis também às pessoas com deficiência, porque se um sistema é confuso e pouco prático para a maioria dos usuários, vai ser ainda mais difícil para usuários que tiverem problemas de acessibilidade. Uma questão mais específica que eu não tinha conhecimento, é a respeito de leitores de tela: segundo o estudo descrito no artigo Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers, os entrevistados utilizam os leitores de tela em uma velocidade incrivelmente rápida, pois assim como os demais usuários, eles buscam pelos conteúdos sem necessariamente analisar com calma toda a página. Eles examinam com seus ouvidos e decidem se aquele conteúdo é importante ou se pode avançar para a próxima seção. Desta forma, é essencial que as páginas sejam estruturadas tendo também uma ordem lógica, permitindo estes terem acesso à mesma facilidade de identificação dos usuários que enxergam. A utilização de estilos CSS ao personalizar as páginas permite adicionar uma série de recursos de acessibilidade, como manter o código fonte com uma ordem de informações com sentido para usuários de leitores de tela, porém dispor de forma diferente suas posições visualmente na tela. Além disso, é possível personalizar o tamanho de imagens e textos para usuários com baixa visão. No momento de programar, existem elementos do HTML que facilitam a identificação por leitores de tela, como “label” identificando o texto correspondente a um campo de formulário e “alt” na inserção de texto alternativo para imagens. As necessidades de acessibilidade vão muito além dessas, e tenho entendido que não será possível aplicar todas a esta versão do sistema, mas o possível por enquanto já aperfeiçoa a realização deste protótipo e abre para novas ideias e implementações nas versões futuras. 27 WEB APP Mesmo com amplo acesso através de dispositivos móveis, o público entrevistado é dividido sobre a preferência entre um sistema Web e um App. Essa divisão é justificável quando se considera a necessidade de espaço de armazenamento nos aparelhos ao fazer a instalação de novos aplicativos e a crescente facilidade de acesso a sites por meio de smartphones através do design responsivo. Ambas estratégias não se anulam, porém foi necessário escolher por onde começar, e websites garantem acesso universal e multiplataforma. Como mencionado por Lopes (2014), grandes empresas como Facebook, Google e Twitter - aqui também consideradas referências projetuais - hoje possuem Apps voltados a diferentes plataformas, mas somente desenvolvidas depois da consolidação por meio de um site mobile, em funcionamento ainda hoje. O desenvolvimento destes era inicialmente apenas Web, sendo posteriormente atualizado para suporte mobile e por fim Apps específicas foram criadas. A Web apresenta uma série de vantagens quando comparada a aplicativos nativos. Ela é multiplataforma, hoje diversos tipos de aparelho possuem navegador, independente do modelo, marca ou sistema operacional. Desenvolver para Web alcança mais pessoas, mantendo o acesso mais democrático e acessível, sem a necessidade de criar diversas versões adaptadas a cada tipo de dispositivo. Além disso, é totalmente descentralizada. Um site não demanda instalação, não requer o carregamento do sistema todo, apenas da página atual, somente solicita permissões ao 28 usuário quando for necessário, sem pedir todas de uma vez, não fica dependente das lojas de aplicativos aprovarem a aplicação, mediarem o uso, limitarem a divulgação. Também a respeito de atualizações, uma página Web sempre vai exibir a versão mais recente, enquanto o aplicativo nativo demanda o download e instalação caso existam novas versões. Referente à acessibilidade, as aplicações Web também permitem ao usuário aplicar zoom livremente, recurso este que é restrito nas aplicações nativas, mas muito útil em termos de acessibilidade. Contudo, a possibilidade de um App não é totalmente descartada. Mesmo com as mesmas funções e conteúdos, um usuário final percebe se está usando um site ou um aplicativo, e pensando na usabilidade do mesmo, uma ou outra opção pode fazer mais sentido a cada caso, trazendo a experiência final mais apropriada. Com o intuito de melhor atender ao público, uma tecnologia possível de ser utilizada no desenvolvimento deste sistema é a criação de uma Progressive Web App. Como descrito no Developers Google, um site pode se tornar um aplicativo confiável e instalável por meio de aprimoramentos progressivos dos recursos para navegadores, utilizando ‘service workers’ e um manifesto de Web App. As Progressive Web Apps permitem que uma aplicação Web seja instalada em qualquer dispositivo utilizando o mesmo código. Este será o objetivo esperado após o desenvolvimento total do projeto. Inicialmente desenvolvido como um site responsivo e mobile-first, que, ao ser implementado, também permitirá ao usuário a instalação e utilização como um aplicativo, tudo utilizando um mesmo código fonte. A Proposta 30 Finalizada a etapa de pesquisa, precisei fazer um filtro entre as funcionalidades essenciais, desejadas e possíveis de aplicar em uma versão inicial do sistema, pensando não somente a nível de protótipo visual, mas também como uma primeira versão a ser programada e implementada mais facilmente. A respeito do sistema de forma geral, foi necessário dividir os tipos de usuário, onde cada um terá diferentes permissões, sendo Ritmista a categoria padrão de todos os usuários e cada Diretoria Administrativa e de Naipes tendo seu acesso personalizado. Para possibilitar isso, foi necessário um sistema de login com usuário e senha. Escolhi 7 funções principais entre as elencadas no questionário e entrevista e algumas que considerei importantes considerando também as minhas experiências dentro da Bateria e meu conhecimento das possibilidades ao programar um Web App: Acesso aos vídeos: uma das funções principais, visto que foi o motivador da existência deste projeto. Acervo de vídeos com busca por texto e por filtros (tipo de conteúdo, naipe e ano), visualizar e fazer comentários. Será permitido apenas aos diretores de naipe a inclusão e exclusão dos vídeos, assim como a edição das etiquetas utilizadas como filtro. Todos podem visualizar e comentar. Galeria: para armazenar as fotos da Naumteria em eventos, todos podem inserir, visualizar e comentar (fica registrado quem fez o upload). Com uma função de fazer uma observação, caso tenha algo de errado com a imagem, notificando a Diretoria de GP para resolver, excluindo ou ocultando a imagem. 31 Agenda: página com o calendário geral das atividades da Naumteria, como ensaios, eventos e reuniões. Seria permitido a todas as Diretorias inserir, alterar e remover compromissos da agenda. Permitido aos Ritmistas visualizarem a agenda e os acontecimentos registrados. Spotteds: permitido a todos enviar, visualizar e comentar mensagens públicas direcionadas a pessoas específicas, grupo de pessoas ou à Naumteria como um todo. O envio acontece por um formulário, podendo ser anônimo ou não, e a Diretoria de GP gerencia as respostas, verificando se o conteúdo poderá aparecer para todos. Feedback do Ensaio: permitido a todos enviar, através de um formulário anônimo com: data, conteúdo do ensaio e feedback, suas opiniões a respeito de determinado ensaio. A resposta pode ser direcionada. Se não for, aparece para todas as Diretorias de Naipe e sempre para a Diretoria de GP. Presenças: cada usuário tem acesso à sua presença pessoal, registrada pelos Diretores de Naipe e gerenciada pela Diretoria de GP quando necessário. Ouvidoria: formulário para dúvidas, críticas e sugestões, acessível a todos os membros, que envia as novas respostas para a Diretoria de GP fazer o encaminhamento necessário. 32 Funções gerais também foram necessárias, como solicitação de cadastro, sistema de redefinição de senha, inserção e gerenciamento de usuários, regulada pela Diretoria de GP, e alteração de perfil pessoal, podendo ser realizada por cada usuário, além de algumas opções visuais como visualização das telas em modo de cor escuro. As mecânicas de cada funcionalidade, divisão de responsabilidades entre as Diretorias, e as permissões dos usuários, foram definidas sempre pensando nas regras já existentes dentro da instituição, definidas nas Reuniões Gerais ou Reuniões Administrativas e no Estatuto Interno. No momento de escolher as funções e como elas seriam apresentadas, tive em mente o público-alvo do projeto. Considero isso muito importante, ser um sistema que faça sentido pensando na identidade da Naumteria e na personalidade de seus membros. Muito ainda pode ser incluído, mas por exemplo: a função de Spotted não é essencial neste primeiro momento, isso já é feito hoje através de Google Forms, porém, é uma funcionalidade que, ao existir no sistema iria aumentar o uso do mesmo de forma recorrente, mesmo antes dos vídeos serem transferidos para a plataforma, além de fazer sentido para o contexto da Bateria. Assim como a utilização de Nome de Usuário no sistema. Já é solicitado o nome da pessoa e o apelido, porém para deixar o sistema ainda mais identificável e personalizável, existe um espaço para o nome de usuário, dando abertura para piadas internas. Escolhas como essas deixam o sistema mais único, diferenciando ainda mais de plataformas existentes e compartilhando uma identidade com o cliente, nesse caso a Naumteria. Desenvolvimento 34 IDENTIDADE VISUAL Planejei a identidade do sistema com base em elementos da marca da Naumteria, mesclado a convenções definidas após uma análise de algumas das referências indicadas no questionário: Twitter É uma rede social bastante utilizada pelos membros da Bateria. Para mim, é muito característica a navegação entre as páginas, então me baseei em elementos dela para tornar mais intuitiva a forma de utilizar o site em construção. A maneira como alterna entre seções com rolagem de tela, por exemplo das páginas “Tweets”, “Tweets & replies”, “Media” e “Likes” na imagem à direita. Também o modo de acesso ao perfil do próprio usuário pela sua imagem de perfil no canto superior esquerdo da página e o layout das publicações no feed, na imagem da esquerda. Figura 07. Página inicial do Twitter. Fonte da imagem: Link Figura 08. Perfil de usuário do Twitter. Fonte da imagem: Link https://play.google.com/store/apps/details?id=com.twitter.android&hl=pt_BR&gl=US&pli=1 https://play.google.com/store/apps/details?id=com.twitter.android&hl=pt_BR&gl=US&pli=1 35 Instagram Outra plataforma muito popular entre os ritmistas da Naumteria, o Instagram foi a referência que utilizei para disposição de imagens, tanto para as publicações, como a exibição em grade. Também na página de perfil, a distribuição das informações do usuário ao lado de sua foto de perfil (neste caso quantidade de publicações, seguidores e seguindo) Facebook O Facebook já foi bastante utilizado como método de organização da própria bateria, então não poderia ficar de fora das referências. Nele algo muito característico que imagino utilizar em uma versão futura é as reações às publicações. Também a disposição das opções de “Comentar” e “Compartilhar”, tal qual é mostrado na imagem abaixo. Figura 09. Perfil de usuário do Instagram. Fonte da imagem: Link Figura 10. Página inicial do Facebook. Fonte da imagem: Link https://play.google.com/store/search?q=instagram&c=apps&hl=pt_BR&gl=US https://play.google.com/store/search?q=facebook&c=apps&hl=pt_BR&gl=US 36 Google Drive Esta ferramenta também já conhecida e familiar para a instituição é uma referência na disposição de arquivos, afinal para este projeto será necessário armazenar e organizar uma grande quantidade de informações em diferentes formatos. Nela os itens são apresentados tanto em grade como em lista e existe uma barra de busca no topo. Como já mencionado anteriormente, na web é muito importante o uso de convenções, para que um sistema seja intuitivo e autoexplicativo. Uma demonstração disso é simples observando as semelhanças entre as três redes: uma foto redonda ao lado de um nome sempre é a foto de perfil do usuário, este nome vem em negrito, as publicações são acompanhadas do autor e do momento da publicação (data ou horário), para usuários específicos existem símbolos que os identificam (como o símbolo de verificado para ambos, símbolo de administrador em grupos do Facebook). Figura 11. Pasta de arquivos do Google Drive. Fonte da imagem: Link https://play.google.com/store/search?q=google%20drive&c=apps&hl=pt_BR&gl=US 37 #0B3A5B As cores utilizadas foram as três do logo da Naumteria, somadas a cores de apoio derivadas destas originais. #E8C31D #FFE675 #628695 #000F18 #1A6E93 Figura 12. Logo Naumteria. Acervo pessoal. 38 A tipografia escolhida foi a Nunito, variando o peso conforme a relevância das informações, como discutido anteriormente. Também foram utilizados elementos visuais da FontAwesome, uma fonte web especialmente voltada para a utilização de ícones em layouts para a Web. Nunito ExtraLight, Regular, ExtraBold Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz 1234567890 ?/:;-_+=* FontAwesome Regular Solid Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz 1234567890 ????-???? 39 Para cada Diretoria de Naipe e Diretoria Administrativa, pensei em um ícone para ficar próximo ao nome da pessoa (assim como o ícone de verificado). Desta forma, seria possível aos usuários identificarem facilmente quem são os diretores da gestão atual e se uma publicação foi feita por um deles. Os símbolos escolhidos foram estes, selecionados no site The Noun Project: Mestre Ação Social Caixa Recursos Ganzá Eventos Surdo Patrimônio Agogô Comunicação Ripa GP Tamborim Externos Harmonia Produtos Figuras 13 a 28. Ícones das Diretorias de Naipe e Administrativas. Acervo pessoal. 40 SKETCHES O desenvolvimento começou a partir de esboços, pensando nas principais telas necessárias para executar as funções que ficaram definidas. Os desenhos são focados na disposição para exibição em dispositivos móveis, mobile-first. Neles já são definidas as primeiras convenções visuais do sistema. Figura 29. Sketch das telas do sistema. Acervo pessoal. Figura 30. Sketch das telas do sistema. Acervo pessoal. 41 SITEMAP Foi realizada a criação de um mapa do site, utilizando a plataforma Miro, para verificar as relações entre páginas, entender se faltou alguma tela ou alguma etapa no caminho do usuário. Figura 31. Mapa das telas do sistema. Acervo pessoal. 42 Figura 32. Mapa das telas do sistema, versão das Diretorias de GP e Naipes. Acervo pessoal. 43 WIREFRAMES Em seguida foram desenhados os wireframes, como uma versão digital dos esboços da página. Esta etapa foi feita já no Adobe Xd, software utilizado até o fim do desenvolvimento visual. Figura 33. Wireframes das telas do sistema. Acervo pessoal. 44 Figura 34. Wireframes das telas do sistema. Acervo pessoal. 45 PROTÓTIPO Ainda através do Adobe Xd, fiz o design final das telas, utilizando a identidade visual do sistema e o conjunto de funções e requisitos esperados. Desde a primeira versão, foram identificadas páginas necessárias que não foram previstas nas etapas anteriores. Figura 35. Versão final das telas do sistema. Acervo pessoal. 46 Além desta versão, afim de aumentar a acessibilidade e melhorar a usabilidade, também desenvolvi as versões em modo escuro e com fonte aumentada do sistema: Figuras 36 e 37. Versões alternativas das telas do sistema. Acervo pessoal. 47 Com a ferramenta de prototipação do software, foi possível finalizar um modelo navegável. Esta ferramenta permite selecionar elementos ou áreas que, ao serem clicadas, levam a outra tela. Ao final, utilizando a Adobe Creative Cloud, o programa gerou um link para compartilhamento do protótipo. Links para o protótipo: versão geral (Ritmistas), versão da Diretoria de GP, versão da Diretoria de Naipes. Figura 38. Relação entre telas para o protótipo do sistema. Acervo pessoal. https://xd.adobe.com/view/73f5e86c-7690-4ea7-bfd5-19c00f632d70-26a6/?hints=off https://xd.adobe.com/view/2adc58ed-bfab-4dc5-8833-38ea9d7d4afb-7f8f/?fullscreen&hints=off https://xd.adobe.com/view/562182a3-e666-474a-8882-39b520df18ab-0372/?fullscreen&hints=off https://xd.adobe.com/view/562182a3-e666-474a-8882-39b520df18ab-0372/?fullscreen&hints=off Fase de Testes 49 Ainda no seu livro sobre a usabilidade, Krug fala sobre o Mito do Usuário Médio. Não há forma de definir que uma preferência qualquer seja a favorita da maioria das pessoas. Apesar da data de publicação do livro, isso permanece ainda nos dias de hoje, como vimos através do questionário, poucas perguntas tiveram um consenso nas respostas. As formas de usar a Web são ainda muito plurais, tanto pela existência de diversos dispositivos, como pelo contexto diferente de cada pessoa com suas vivências na rede, os diversos tipos de acesso e níveis de conhecimento. Isso sem mencionar a acessibilidade necessária para abranger a todos os usuários. Não existe um consenso sobre uma ferramenta específica tida como a melhor de todas. A única forma de saber se algo funciona é a partir de testes. Inicialmente eu pensava que só poderia testar meu projeto se chegasse a uma versão programada dele, integrado ao banco de dados, onde os participantes dos testes pudessem de fato interagir com esta hipotética versão beta. Mas lendo este livro, percebi a possibilidade de fazer testes a partir de qualquer versão, mesmo ainda com apenas esboços. E quanto mais cedo os testes são realizados, mais confortáveis os usuários ficam para apontar possíveis problemas, por verem que ainda está em desenvolvimento e é um momento adequado para dar sugestões de mudança. Uma forma explicada por Krug de como fazer testes desde a concepção, é simplificá-los o máximo possível. Se não puder fazer em um laboratório com uma equipe especializada, mudar para uma sala ou escritório. Ele considera mais importante realizar testes regularmente a cada etapa ao invés de realizar o teste mais bem estruturado uma única vez. Pensando desta forma, a recomendação é de, no máximo, três a quatro usuários a cada rodada de testes. E se o público for dividido em grupos claramente definidos, tentar realizar testes com representantes de cada grupo - neste caso, os usuários se dividem entre Ritmistas e Diretores com funções administrativas. O teste descrito por ele pode ser de dois tipos: teste de compreensão, onde é mostrado o sistema e observado se o usuário entende o objetivo do mesmo, como ele está organizado, como funciona; e teste de tarefas- chave, onde é solicitado ao usuário que faça algo e se observa como ele realiza. O teste todo é acompanhado presencialmente por um aplicador, com gravação de voz e gravação da tela para análise posterior, se possível ainda no mesmo dia, com o objetivo de examinar os resultados e como isso impacta no sistema. Uma forma de medir a usabilidade quantitativamente em testes defendida por Fabrício Teixeira, especialista em User Experience Design e autor do livro Introdução e boas 50 práticas em UX Design, é através de escalas numéricas de usabilidade. Aqui estarei usando o System Usability Scale (SUS), método criado por John Brooke em 1986 que avalia a efetividade, eficiência e satisfação do usuário. Funciona através de um questionário com 10 perguntas pré definidas, onde o usuário responde em uma escala de 1 a 5 de 1 - discorda completamente ou 5 - concorda completamente. Foi aplicado através deste questionário desenvolvido no Google Forms: 51 52 53 Para que funcione, é necessário que sejam estas perguntas aplicadas nesta ordem. A forma pode ser tanto por questionário impresso ou de forma digital, como fiz. O ideal é que seja aplicado após o usuário realizar tarefas específicas relacionadas ao sistema ou produto em desenvolvimento. Com as respostas, é feito um cálculo para chegar à pontuação final de avaliação do objeto de estudo. As contas necessárias são as seguintes, realizadas individualmente para cada resposta obtida por cada entrevistado: • para as respostas ímpares (1, 3, 5), subtraímos 1 da pontuação que o usuário respondeu • para as respostas pares (2 e 4), subtraímos a resposta de 5. Ou seja, se o usuário respondeu 2, contabilizamos 3. Se o usuário respondeu 4, contabilizamos 1 • Agora somamos todos os valores das dez perguntas, e multiplicamos por 2,5 O resultado pode ir de 0 a 100, sendo a pontuação média 68. Abaixo disso o sistema provavelmente apresenta muitos problemas. A partir destes dois métodos, elaborei como seriam efetuados os testes na plataforma: Ritmista (usuário padrão) Teste realizado de forma presencial com 4 pessoas, todas sendo membros da Bateria, Diretores ou não. Realizado com gravação da tela e gravação de voz. A cada pessoa foi feita uma breve explicação do sistema e do intuito da pesquisa, em seguida solicitado realizar o mesmo conjunto de tarefas, sempre descrevendo o que ele acha necessário fazer nos casos onde o protótipo não era interativo o suficiente para simular: • solicite seu cadastro • faça login no sistema • encontre o vídeo do Breque Tempo tocado pela Caixa • veja as fotos da Formatura da FAAC de 2023 • verifique a agenda da Naumteria • envie um feedback de ensaio • explore as demais funcionalidades do sistema que você ainda não viu, pode comentar como acredita que elas funcionem 54 Diretoria de Gestão de Pessoas (GP) Teste realizado da mesma forma com 2 pessoas, desta vez sendo membros da Diretoria de GP. Feito com gravação da tela e gravação de voz, com o seguinte conjunto de tarefas: • faça login no sistema • acesse a área da Diretoria de GP • finalize o cadastro de um membro • insira a reunião geral na agenda da Naumteria • verifique os novos spotteds • verifique as mensagens da ouvidoria • inclua Lei Murilo para um ritmista • explore as demais funcionalidades do sistema que você ainda não viu, pode comentar como acredita que elas funcionem Diretoria de Naipes Teste realizado da mesma forma com 2 pessoas, agora membros da Diretoria de Naipes. Teste com gravação da tela e gravação de voz, mas com outro conjunto de tarefas: • faça login no sistema • faça o upload de um novo vídeo • insira um ensaio de naipe na agenda • registre a presença do ensaio • veja os feedbacks de ensaio • explore as demais funcionalidades do sistema que você ainda não viu, pode comentar como acredita que elas funcionem Nesta etapa foi possível observar que o sistema geral, versão de Ritmistas, está bastante intuitivo, a maioria das questões que os usuários tiveram, aconteceram por conta de limitações do protótipo, como função de deslizar a barra de links e mensagens de confirmação ao concluir as ações. Ou ainda, dúvidas de conteúdo, dada a ausência de um banco de dados. O teste da Diretoria de GP foi bem diferente entre os usuários. Ainda sendo o mesmo sistema e as mesmas tarefas a serem realizadas, houveram dificuldades para uma pessoa enquanto para a outra estava bastante intuitivo. E isso é normal em todo sistema ou produto, cada usuário pode ter mais facilidade ou dificuldade. A respeito das funcionalidades, pude observar que: 55 • está claro como realizar o acesso à Área de GP • o cadastro de membros foi bem aceito desta forma, com algumas informações a serem completadas por GP depois de confirmar a identidade de quem solicitou • a função de inserir acontecimento na agenda, foi buscada na área de diretoria, antes de procurar por ela na agenda. Então é válido colocar em ambas telas uma opção que direcione o usuário para esta funcionalidade, deixando-a acessível por mais de um caminho • os spotteds e a ouvidoria foram acessados e manipulados sem problemas • já na função de registro de presenças, foram feitos levantamentos a respeito de exceções. Por exemplo: “como ficaria registrada em um dia no qual o ensaio foi cancelado?”. Mas assim como outras questões, é uma logística a nível de código, a ser discutida no momento da implementação No protótipo da Diretoria de Naipes, também percebi algumas questões: • estava pouco claro como inserir vídeos. Visto que não havia um atalho na página “Vídeos”, demorou um pouco mais para os usuários encontrarem como fazer. Após esta observação, entendi que é válido alterar o modelo e deixar este atalho tanto na área da Diretoria de Naipe, como na página de Vídeos. • na função de inserir evento na agenda, percebi que faltava a opção de escolher a data do acontecimento e que poderia ser útil acessá-la também clicando no dia, uma ideia que tive ao olhar o sistema sendo testado. • o local do registro de presenças estava intuitivo como chegar, mas não tão intuitivo como anotar as presenças. No calendário aparece um símbolo de confirmação em azul para os dias que teria sido feito o registro e um símbolo de exclamação em amarelo para os dias que faltam incluir, então ao clicar nestes dias o usuário é levado ao formulário de presença. Uma forma de resolver é incluindo um aviso de quantos ensaios faltam incluir a presença, acompanhado do ícone de exclamação, para deixar mais claro quais são os dias, e um botão “Registrar todas”, que futuramente apresentaria o formulário de presença em ordem cronológica. Além disso, inserir um balão de pop-up para indicar à pessoa que existe uma ação que demanda sua atenção ali: não foi feita a presença de algum ensaio. 56 Senti que no momento de colocar o sistema em prática, seria interessante fazer uma reunião expositiva para explicar aos diretores as funcionalidades. O sistema é intuitivo o suficiente para dispensar a existência de um manual escrito ou gravado. Mas em uma conversa com os usuários, a troca é muito rica, tanto para entender as demandas pessoais como para identificar possibilidades de crescimento da plataforma. Após os testes, todos tiveram o mesmo questionário SUS para responder. Com base nas regras de pontuação estipuladas, a média final foi de 93,22 que, nos parâmetros definidos pela ferramenta, é excelente. 57CO NS ID ER AÇ ÕE S FI NA IS Apesar de já ter desenvolvido alguns sistemas Web anteriormente, meu foco sempre esteve na parte da programação, que era a minha base. Desta vez, percebi a importância de me dedicar também ao processo de design que vem antes da programação. Ao planejar cada decisão, entender as necessidades do usuário, realizar testes e corrigir erros, aprendi que o processo todo não é tão autônomo como eu pensava. Mesmo em uma equipe de desenvolvimento, é essencial a participação do cliente, do público-alvo, ou ainda de personas para entender o que funciona e o que precisa ser adaptado pra ter a adesão desejada. E o mesmo acontece em muitos processos criativos: as vezes criamos algo pensando em uma função específica, mas, ao final, o usuário que define como vai utilizar, é preciso ouví-lo. Em relação a este projeto em específico, vejo grandes possibilidades de implementação, pois foi planejado pensando nas necessidades e interesses do público desde o início, considerando as particularidades da Naumteria e de seus membros. Ele pode facilitar a comunicação interna e organização das atividades administrativas e, além das funções mencionadas aqui, é possível pensar em próximas versões com ainda mais recursos, acrescentando gradualmente conforme for possível e necessário. Com a diversidade de cursos oferecidos no câmpus da Unesp Bauru, também vejo a possibilidade de futuras gestões manterem o sistema ativo, não apenas em termos de Design, mas também na parte de Tecnologia de Informação, teria abertura para novas pessoas contribuírem no desenvolvimento. 58 À minha familia, em especial ao meu irmão Raul e ao Leo, que sempre me ouviram e foram, respectivamente, o equilíbrio entre apoiar minhas ideias mais malucas e me trazer de volta pra realidade, para fazer o que era melhor pra mim. Também aos meus pais, que, de muitas formas, ajudaram no meu processo para me manter em Bauru, como que me fazia mais feliz - inclusive a receita do pão de mel que vendi todos esses anos foi criada por eles. A todos os meus amigos, tanto anteriores a Unesp, como os que me aproximei durante essa jornada. Amigos de sala, veteranos, toda a gestão da CoCa19 e do Taquara. Em especial a Mayara, Vera, Akemi e Capi, que me acompanharam por tanto tempo, sem elas eu seria uma pessoa completamente diferente. Um agradecimento que não poderia faltar à Naumteria e todos que fazem ela existir. Desde o início sempre me senti acolhida e falo com toda certeza que não seria possível chegar até aqui se não fosse por ela e todas essas pessoas. Principalmente a quem eu me aproximei nesse último ano quando voltei pra Bauru pós-pandemia, foram e são muito importantes. Por fim, à minha orientadora Profa. Dra. Ana Bia e meu coorientador Prof. Me. Guilherme, por me guiarem e apoiarem no processo. À Profa. Larissa que também auxiliou no início da pesquisa, à Profa. Dra. Cássia e à Yumi por aceitarem o convite como banca, e aos demais professores que tive por todos os aprendizados durante o curso. AG RA DE CI M EN TO S 59 RE FE RÊ NC IA S -sus-system-usability-scale-e-como- -us%C3%A1-lo-em-seu-site-6d63224481c8 ALLSOPP, John. A Dao of Web Design. A List Apart, 7 abr. 2000. Disponível em: https://alistapart.com/article/dao/. Acesso em: 18 jun. 2023. COMITÊ GESTOR DA INTERNET NO BRASIL. TIC Domi- cílios: Pesquisa Sobre o Uso das Tecnologias de Informa- ção e Comunicação nos Domicílios Brasileiros. São Paulo, 2022. DEVELOPERS GOOGLE A. Progressive Web Apps: Pro- gressive Web Apps are now supported on the desktop!, 9 maio 2019. Disponível em: https://developers.google.com/ web/progressive-web-apps/. Acesso em: 18 jun. 2023. FERGUSON, Jeremy. Smartphones sales pass PC sales for the first time in history!. Internet Archive. SmartOn- line, 10 fev. 2011. Disponível em: https://web.archive. org/web/20110213115230/http://www.smartonline.com/ smarton-products/smarton-mobile/smartphones-pass-p- c-sales-for-the-first-time-in-history/. Acesso em: 18 jun. 2023. GOOGLE INC. Central da Pesquisa Google. Práticas re- comendadas para sites móveis e indexação que prioriza dispositivos móveis, 2023. Disponível em: https://develo- pers.google.com/search/docs/crawling-indexing/mobile/ mobile-sites-mobile-first-indexing?hl=pt-br. Acesso em: 18 jun. 2023. GUIDELINES for Accessible and Usable Web Sites: Obser- ving Users Who Work With Screen Readers. Maryland, 1 jan. 2003. Disponível em: https://redish.net/wp-content/ uploads/Theorfanos_Redish_InteractionsPaperAuthors- Ver.pdf. Acesso em: 18 jun. 2023. KRUG, Steve. Não Me Faça Pensar: Uma Abordagem de Bom Senso à Usabilidade Web. 2. ed. Rio de Janeiro: Alta Books, 2008. LOPES, Sérgio. A Web Mobile: Design Responsivo e além para uma Web adaptada ao mundo mobile. São Paulo: Editora Casa do Código, 2014. TEIXEIRA, Fabrício. O que é SUS (System Usability Scale) e como usá-lo em seu site. Medium. UX Collective BR. 3 ago. 2015. Disponível em: https://brasil.uxdesign.cc/o- -que-%C3%A9-o TACATICAWEB Construção de uma Plataforma Digital para a Gestão da Naumteria