Versão final TCC entrege: etapa finalmente concluída

Após um longo hiato, notícias, para poder virar a página e/ou buscar novos rumos… A apresentação aconteceu na data prevista – 27 de junho, depois de um adiamento devido à suspensão das atividades na UNEB durante Copa + São João. Fiquei nervosa e tive muito medo de ser questionada e de que apontassem erros ou falhas metodológicas. Essa aliás foi a razão de eu ficar nervosa – o medo de haver erros graves. Houve questões a pontuar, o professor Alexandre Lenz, convidado para compor a banca, fez muitas observações importantes (queria ter recebido alguns daqueles feedbacks antes!). Havia espaço para ser melhor, mas acho que no fim o trabalho ficou mais interessante do que eu me sentia capaz de fazer e creio que isso me fez bem, me ajuda a ver que tenho potencial de construir coisas relevantes, e, também, de concluir projetos. Estou feliz por ter conseguido, após tantas idas e vindas, apresentar.

Mais de um mês depois, já em agosto, afinal entreguei a versão final da parte escrita, buscando refinar o trabalho com as considerações feitas no dia da banca. Confesso que não consegui me dedicar para realizar isso e que não fiz todas as alterações. Algumas porque não concordei, então refleti sobre o que havia sido dito, busquei meus argumentos e mantive como estava. Outras porque não sabia como faria e infelizmente, após todo esse processo, já me surgia novamente um desânimo advindo da sensação de que ninguém se importa muito com esse trabalho, lá dentro: professores, avaliadores etc – é algo pontual que será em grande parte esquecido, salvo se por acaso algum estudante que buscar fazer um tcc com algum nível de alinhamento se lembrar de procurar por lá. Isso tirou um pouco minha motivação de continuar mexendo naquele projeto. Não porque a temática seja desinteressante, mas porque me pareceu um esforço sem propósito. Pra reduzir essa aridez que sinto em relação a esse processo, fica aqui disponível o link para quem quiser ler a monografia.

O título da versão final do projeto é: Inspeção e Evolução da Usabilidade de Buscadores Tipo Diretório: Estudo de Caso com o fazDelivery.

Para os “slides” da apresentação (é interessante porque há imagens comparando as interfaces do fazDelivery, nele), visite o prezi.

É isso, a partir de agora, esse blog talvez se torne mais experimental/ pessoal e menos profissional. Mas ainda conterá, de algum modo, meus aprendizados, reflexões, caminhos e o andamento de alguns projetos, com sorte. Gracias a tod@s que de algum modo me acompanharam nessa longa trajetória. (:

Advertisements

é amanhã ‘-‘

às oito da manhã

estou nervosa

>.<‘

Sobre a necessidade de testes de usuário

E o rigor de sua execução.

Encontrei esse artigo sobre isso: http://www.lits.dei.uminho.pt/tu.pdf

Quero ler, acho que é interessante também pelas dificuldades que tive com essa etapa.

Dias mais de descanso…

90% são só 50%. E – Hello, world!

Sábado de manhã (07 de junho) rolou a “pré-banca”. Vai assim entre áspas porque foi bem informal, e como não sei como costuma ser, me dá a sensação de que não foi uma pré-banca lá muito convencional. Mas foi o que o eu precisava, no momento, e serviu para eu apresentar a Eduardo Jorge a estrutura da apresentação que quero fazer, discutindo os conteúdos que quero trazer em cada etapa, recebendo feedbacks para cada parte. Também foi o momento de ele ver os protótipos resultantes do trabalho, dos quais ele gostou. Essas duas coisas (discutir a apresentação e ele gostar dos protótipos), aliadas ao fato de que, mais cedo, havia enviado uma versão final da monografia para ele, João e Alexandre Lenz, professor convidado para a banca, me deixaram muito tranquila, com a sensação de que… acabou. Pois é. Assim. Antes mesmo da banca. O_o’

É que a banca estava marcada para o dia 13 de junho, próxima sexta, e isso me fez dar uma corrida louca na última semana (especialmente de terça até sábado), para garantir que teria um v1 de tudo até sexta passada, para cumprir o cronograma. Só que sábado, quando cheguei, exausta, à UNEB, descobri que as atividades acadêmicas só voltariam depois do São João (ou seja, dia 25), ficando portanto impossível apresentar a banca dia 13. AAAAAAAAAAaarrrrrrrrrrrrrrgh. Me dá meu alívio de terminar logo esse negócio!! D: Dá! Não dá?! Hm… Vamos pensar de novo. Eu entreguei a monografia na correria alolka, quase que vai com erros de digitação como sesção no meio. Me esforcei para incorporar as sugestões de João e Eduardo, mas havia deixado pelo menos uma coisa mais importante de fora. E tinha feito a conclusão quase nos últimos minutos da prorrogação do segundo tempo – nem reli a bichinha, pedi pra mãe fazer isso, porque eu não tinha qualquer condição de entender leituras, mais, depois de virar todas as noites desde terça.

Isso significava que as chances de haver trechos muito ruins de compreender e carentes de uma reescrita eram grandes, e que uma boa revisão, com calma, cairia bem ao trabalho. Então, por que não aproveitar esse tempinho a mais, e fechar essa etapa com mais tranquilidade? Afinal, não foi pra isso que quis adiantar o calendário, em primeiro lugar? Beleza, então. Vamos ver o que eu gostaria de fazer pra considerar essa v1 concluída de forma mais bonita, e fazer. Sem perder a sensação de que, sim, consegui – conclui esse negócio, fui capaz, e agora posso começar a me sentir livre para começar uma nova etapa, ir atrás de outros desafios… *_*

Foi bacana. =)

Enquanto não acaba por completo, alguns comentários variados:

Sobre estar terminando algo – li n’A arte cavalheiresca do arqueiro zen:

A quem deve caminhar cem milhas, recomendamos que considere noventa como sendo a metade.

Herrigel Eugen

Isso pra mim fala tanto de como costumamos errar quando tentamos prever o esforço necessário para terminar algo, como também tenta explicar como qualquer etapa final tende a ser tão ou mais trabalhosa do que todo o resto de um percurso – há detalhes, finalizações, polimentos… E todo o cansaço acumulado da jornada já percorrida. Eu senti um tanto isso. Ainda que considere que tenha, no fim das contas, doído menos do que imaginei que poderia (fico feliz com isso!).

Para conseguir o pique necessário pra enfrentar as madrugadas da semana passada, primeira, segunda, terceira, quarta noites, criei uma playlist no Grooveshark (uma plataforma para ouvir músicas com características de rede social) com clássicos da época em que virávamos noite no ACSO fazendo trabalhos de faculdade ou mexendo em coisas dos robôs. Adicionei algumas músicas que me faziam pensar no que poderia finalmente fazer quando terminasse esse processo todo, chacoalhei, coloquei tudo no repeat e segui, com cara, coragem, saudade e muito café. Como curti o que fiz com a lista de músicas, compartilho aqui:

3, 2, 1 – let’s jam: it’s the final countdown… Under pressure, eu faço tcc até mais tarde e tenho muito sono de manhã… Mas amanhã de manhã, quando a gente acordar, quero te dizer que a felicidade vai desabar sobre os homens. Porque estamos, meu bem, por um triz pro dia nascer feliz and I want to break free… Woo hoo! /o/

Foram momentos divertidos. Haha. Gosto do silêncio e da calma das madrugadas, e ver o dia nascer é algo legal – dá uma vontade doida de pegar a bike e sair pedalando pra ver o nascer do sol. Acho que farei isso em breve.

Agora o corpo acostumou um tanto, está meio difícil dormir cedo, e quero continuar “trabalhando” no TCC. Vai entender…. rsrs.

Por agora é só, pessoal. Mas acabou sem acabar, e como não quero dar uma de Oberyn Martell, vou continuar mexendo nesse negócio até fechar tudo, porque tenho até sexta pra entregar a versão final (de novo!), e dia 27, oito da manhã, essa banca sai. E não quero virar mais nenhuma noite fazendo isso, até lá…

AH! O título do post é porque… CAAaaaaaaaaaarai!!!! De volta à vida! Origami-bike-filme-amigos-praia-livros-viagem-tecido-natação-cuidar-da-casa-cortar-cabelo-trabalhar-conversar-dormir-curtir-fazer-arte sem culpa: aí vou eu!! \o/

[Prototipação] Etapa 1: executando soluções para as violações de heurísticas. Reflexões sobre processo de prototipação

/*

Primeiro, um comentário: muitas vezes me perco, no processo do TCC, porque, ao invés de ver os passos de uma determinada tarefa ou etapa e segui-los à risca, sem pensar muito, começo a inventar firulas, ou tergiversar, ou, ou… e de repente me perco, ou faço mais do que preciso e menos do que devia, ou gastei um tempo danado fazendo coisas complicadas, sem alcançar o objetivo simples. Tudo isso atrapalha um bocado, mas ainda tenho dificuldade de evitar. É um pouco como o processo de leitura, quando de repente se está procurando um monte de artigos que já não estão realmente ligados ao que devíamos fazer, porque vamos saltando daqui pra lá e depois acolá, e não nos damos conta de como estamos nos afastando do objetivo inicial…

*/

Para prototipar, estou usando:

  • experimentações no HTML e CSS da página, através da ferramenta para desenvolvedor do navegador (no Chrome, o atalho pra ela é F12);
  • retoques ou ajustes mais livres utilizando o GIMP, uma ferramenta para edição e manipulação de imagens, de código livre.

Essa abordagem é porque não quero redesenhar a interface do zero, mas sim corrigir ou melhorar aspectos específicos. Se fosse fazer do zero, poderia utilizar ferramentas para criar primeiro protótipos em wire-frame e ir evoluindo a partir daí. Uma limitação que tenho é que não sei trabalhar com front end, ou seja, não tenho domínio de HTML e CSS, de modo que não consigo simplesmente abrir o código-fonte ou algum framework e sair editando tudo daí.

O que estou observando que deveria ter feito diferente, para essa fase de correção e prototipação – o ideal, parece-me agora, é:

  • pensar no conceito que se quer seguir;
  • ter a visão geral do todo – o que é preciso corrigir e onde, todas as correções para cada tela;
  • observar elementos que se repetirão em diferentes telas;
  • utilizar uma ferramenta que permita reaproveitar elementos – com camadas e elementos agrupados, por exemplo -, acredito que não terei problemas com isso no GIMP;
  • corrigir e prototipar a partir das peças menores, componentes, que se repetem em variados pontos do sistema;
  • executar a correção completa dos erros, por telas;
  • e, assim, ir realizando um trabalho de composição.

No momento isso parece um processo mais seguro para evitar retrabalho – por exemplo, eu não segui esses passos, até aqui, e estou mexendo em telas que listam itens de produtos, mas ainda não mexi nos produtos. Se e quando vier a mexer neles, precisarei alterar as telas novamente… O mesmo vale para a barra de busca, que aparece em várias telas (espero que essa seja mais simples de encaixar)… Mais grave ainda do que isso é que executei as correções para as violações de heurísticas e depois terei de fazer mudanças para as correções de testes de usuários, passando por telas em que já trabalhei.

Ah, amanhoje é: pensar e executar soluções para os problemas levantados nos testes de usuários. Ver se consigo seguir as etapas que falei acima. Daí precisarei gerar versões finais, fechadas, de cada tela, que agreguem as soluções das avaliações heurísticas e dos testes… Sim, idealmente, tudo no domingo.

Estou com sono e não revisei esse post. Um dia o releio e descubro barbaridades de escrita. Falta menos de uma semana para entregar a versão completa da monografia para a banca. /suspiro Eu vou sobreviver…

[Andamento] Soluções para os Problemas Identificados

Primeiro, uma observação: a palavra que passei os últimos dias tentando lembrar (até ontem, anyways), para descrever o que sinto que faltou na condução da etapa prática do TCC é… rigor. Sinto que fui pouco rigorosa, principalmente na etapa de testes de usuários como um todo. Tinha pouca (quase nenhuma) experiência prática nesse quesito, e ainda assim planejei e conduzi tudo muito sozinha, o que também não ajudou. =/
No último capítulo, comentei que estava em dúvida entre prototipar ou implementar as soluções pensadas para os problemas. Pedi orientação sobre isso para orientadores e alguns amigos. João Rocha disse que preferia que eu implementasse e fizesse os testes com usuários; EJ sugere que eu faça apenas prototipação e comparação das duas interfaces (porque implementar em si pode trazer complicações extras, erros etc, que tirariam o foco no projeto). Entendo e consigo concordar com os dois pontos de vista. Fazer a implementação mais testes deixaria o projeto mais completo, porque teria seguido todas as etapas previstas pela metodologia que eu mesma apresentei. Mas isso reduz meu tempo de trabalho na prototipação em si, o que também tira qualidade do projeto. Então estava meio “dilemética”.
Ontem então pensei em um meio termo assim:
  • v-1.0: corrigir coisas em protótipo. Possível abordagem mista: selecionar os 10 problemas mais prioritários das avaliações heurísticas, mais os problemas dos testes de usuários. Corrigir.
  • v-1.1: Tendo tempo, implementar e testar;
  • v-2.0: sobrando tempo: corrigir em protótipo demais violações de heurísticas.

Está se encaminhando para eu conseguir fazer a v-1.0. Hoje terminei de descrever como três ferramentas correlatas abordam aspectos considerados problemáticos no fazDelivery. A tabela abaixo mostra uma parte dessa listagem (os Ids servem para identificar a que problema cada linha da tabela se refere – ok, sei que está ruim visualizá-la). Hoje, então, parto pra selecionar as soluções que de fato usarei e prototipá-las…

Excerto do levantamento de soluções correlatas.

Excerto do levantamento de soluções correlatas.

Andamento, observações, redefinição de escopo…

Acabo de enviar uma versão parcial (semi-final) para os orientadores. Agora ficam faltando dois ou três capítulos, sendo que a prototipação das melhorias está nesse meio >.<‘

Algumas questões que ainda persistem, pra mim:

  • Devo apresentar todos os resultados dos testes? Sim, apresentei tanta coisa… O.o’ Precisarei compilar individualmente cada um e acrescentar nos apêndices, de algum modo;
  • Está fazendo falta ter uma listagem de todas as heurísticas violadas. Creio que eu mesma imporei como uma obrigação ter isso para a versão final;
  • Em relação aos testes com usuários, além das tarefas e tempos, tenho de acrescentar no tcc uma listagem dos problemas e dificuldades encontrados. Na verdade, no meu caso, isso é o mais importante, dos testes.

Após as dificuldades que tive hoje para sintetizar e descrever os resultados dos testes de usuários, estou pensando em reduzir o escopo do projeto, evitando implementar de fato a interface e, por conseguinte, a nova rodada de testes de usuários que eu precisaria fazer. EJ perguntou qual seria minha abordagem em relação a isso sábado passado e comentei que iria implementar, mas agora prefiro evitar, e visto que ele levantou a possibilidade, estou esperançosa com a resposta…

Eu acho que tinha mais alguma coisa pra dizer, mas esqueci. Ah, o título provisório está assim, agora: Inspeção e Evolução da Usabilidade de Buscadores Tipo Catálogo: Estudo de Caso com o fazDelivery.

Testes com Usuários – O que é importante sintetizar? D:

Ok, eu tenho uma cacetada de informação relacionada aos testes com usuários. E agora, eu uso o quê, o como? Calculei um bocado de médias, defini metas, fiz teste eu mesma, para servir de benchmarking. Mas agora é hora de descrever os testes, apresentar tais dados, extrair algo de valor deles. comofas/ >.<‘

Já descrevi a parte aberta, subjetiva dos testes. Ainda não caracterizei o perfil dos usuários, por outro lado, nem… consigo usar os números de um jeito que faça sentido. Vamos tentar aqui, primeiro. Menos pressão. Por exemplo, eu defini duas metas:

  • consultas não demorarem mais de 3 minutos;
  • 80% das consultas serem concluídas com sucesso (a definição de sucesso era conseguir encontrar um telefone para um estabelecimento que tivesse o produto pesquisado).

A partir dos dados coletados, é possível observar que aproximadamente 90% das consultas foi concluída em menos de 3 minutos (a média foi 1:29 minutos). Entretanto, isso não impediu que apenas 66% das tarefas fosse considerado concluído com sucesso, e em verdade as médias de duração de tarefas concluídas com sucesso ou abortadas porque o usuário chegou a seu limiar de frustração (1:31 minutos) teve uma diferença de 2 segundos, apenas. Isso pode sugerir duas coisas:

  1. o tempo de duração da consulta não é tão relevante para as pessoas, conquanto que elas não se sintam frustradas com o sistema;
  2. ou, seguindo uma linha oposta, que as pessoas têm uma expectativa de encontrar as coisas muito rápido, o que faria com que 2 segundos fosse um tempo significativo, aqui.

A segunda hipótese, entretanto, não é confirmada pelos dados, pois apenas uma das tarefas concluída sem sucesso de fato ultrapassou os três minutos. A partir disso fico inclinada a pensar que a primeira hipótese é a que faz mais sentido, e que, conquanto o sistema não pareça ser incapaz de atender às demandas dos usuários, o tempo de duração de uma consulta (pelo menos no intervalo de tempos destes testes, em que a consulta mais longa levou 4:10 para ser concluída – com sucesso, por sinal) não é tão relevante para a satisfação do usuário com a ferramenta.

Outro aspecto que observei a partir dos testes foi que algumas pessoas consideraram uma tarefa concluída, mesmo tendo encontrado um estabelecimento diferente do solicitado.

Como tais observações são úteis para o projeto?

  1. tenho mais maturidade para pensar as próximas metas;
  2. fica claro que devo observar, das sessões de testes, os aspectos que mais levaram a frustração, para tentar minimizá-los;
  3. a listagem de resultados não é exatamente eficiente para apresentar informações sobre os estabelecimentos (as marcas são pequenas, o nome tem pouco destaque).

Hm. Ok. Isso me ajuda a me sentir um pouco melhor. Essa é uma história que sinto que consigo contar, que faz sentido dentro de meu processo. Agora vou pedalar, pra ajeitar o juízo e as ideias, e volto pra terminar essa descrição da 1ª rodada de testes com usuários.

EDIT 1: ontem à noite, em algum momento, quando reli isso, não gostei muito do racional. Me pareceu precipitado e errôneo. Talvez não tanto por ele em si, mas porque analisei os dados em mais detalhes e vi que quando baixei a linha de corte para 1:29, que foi a média, o racional parou de fazer sentido at all. Acho que só por “diversão” vou calcular a mediana das durações, depois.

EDIT 2: ok, calculei a mediana de todas as tarefas de consulta: 78.5. A média é 89. O que eu deveria conseguir apreender, disso?

Receios, Dúvidas y otras cositas más

Algumas observações meio soltas, após este dia de escrita.

Em relação aos testes com usuário que fiz até então, tenho receios de que sejam muito frágeis os pontos:

  • Perfil dos usuários;
  • Tamanho da amostra.

Estava em dúvida se deveria listar todos os problemas classificados em relação ao grau de severidade. Entretanto, após criar uma tabela com dez deles e ver o tamanho que ocupou, considerei que era melhor não fazê-lo. Acrescentei, no entanto, o resumo da classificação de severidade do questionário do docs, assim, as informações estão todas lá (e o processo que eu usei para chegar às médias também, então se alguém precisar, ou quiser, pode estendê-lo e ter todos os valores). Com isso, tenho uma primeira versão final da seção que descreve o percurso das avaliações heurísticas…

Observações soltas:

  • eu amo o Google Docs – muito bom ter opção de gerar impressão bonitinha de um formulário online…
  • às vezes me pergunto se o tempo que ganho não precisando formatar o documento no LaTeX não é todo perdido ajeitando tabelas no mesmo… >.<‘

Já comentei aqui que tenho receio de meu TCC estar fraco/ pobre? Caso não, estou comentando agora. Estou evitando pensar nisso, e só seguindo, e explicando meu processo e minhas decisões o melhor que posso, para agregar o máximo de valor possível. Mas, por vezes, a sensação volta, e é ruim. E, dito isto, me lembro que já falei disso, sim.

Andamento: vamos que vamos

Nova possibilidade de título: Inspeção e Evolução da Usabilidade de Interfaces de Buscadores Tipo Catálogo, Estudo de Caso com uma Ferramenta Georreferenciada de Busca de Deliveries acho que é bem realista ‘-‘. Mas coloquei no TeX e compilei e ficou enorme e uma droga. Pensar em outra coisa.

Fui falar pessoalmente com EJ. Ele deu pontuou algumas coisas, fez contribuições realmente interessantes – gostaria que isso tivesse acontecido antes, mas paciência. Apesar das questões levantadas e de discordar de algumas decisões, considera que dá pra apresentar o TCC dia 14. Só preciso conseguir gerar uma versão da mono para ele e João revisarem, ainda essa semana, e corrigir a interface para poder testá-la entre quinta e domingo. E fazer o resto que falta.

Antes de ir lá tinha feito uma outra versão da metodologia, junto com uma descrição mais detalhada e atualizada, e mudei a figura. Após a conversa surigiram mais mudanças a serem feitas. Estou trabalhando nelas agora. Uma dúvida que me surgiu, é: com que granularidade devo (ou deveria) apresentar as coisas, na figura da metodologia?

Estou lutando com meu eu crítico me dizendo que o TCC está muito simples/ pobre… Se eu fosse postergar sua entrega, corrigiria os problemas que puxei para serem classificados na avaliação heurística, daí seguiria o processo primeiramente definido, aproveitando para filmar os testes, que foi algo que EJ pediu. E tentaria fazer mais apropriadamente o processo de prototipação e implementação. Vamos ver o que vai dar pra fazer, com o que tenho.

Ocorreu-me agora há pouco que posso justificar a escolha de problemas escolhidos nas avaliações heurísticas como um recorte da lista completa, para tornar o projeto mais factível dentro de suas limitações. O recorte escolhido, no caso, foi relacionado a aspectos que poderiam levar a erros no fluxo dos usuários, porque a ferramenta entrou em estágio de manutenção (i.e., saiu de evolução e desenvolvimento) ainda com muitas coisas a serem corrigidas.