Seis meses de parkour

E as coisas continuam difíceis. Algumas talvez mais difíceis do que antes.

Não encontrei ainda ritmo, nem caminhos eficientes de lidar com medos e inseguranças, com o ego. Muito mais do que gostaria me sinto cansada e incapaz e fraca. Continuo me perguntando se faz sentido eu continuar tentando isso, quando tudo parece tão difícil, quando tantos movimentos que “todos” consideram fáceis são pra mim obstáculos que travam meu peito de medo.

Eu nem vim aqui pra falar do parkour, ia falar sobre ritmo, sobre encontrar o modo do corpo funcionar que me permite continuar treinando (ou pedalando, ou o que for) sem que eu precise parar, sem que eu precise me distanciar da prática. E eu ia falar que fico me questionando, e pensando que eu não quero me sentir uma iniciante pra sempre em tudo, e uma parte minha pensa – “Então, tá. No que você quer ser boa?” Porque, em parte, é uma questão de escolher a que você vai se dedicar… É inevitável melhorar, se você escolher algo e praticar consciente, persistente e continuamente. E se você olhar para a sua trajetória para entender a melhora – essa é uma das partes mais difíceis pra mim. Em quase tudo e, no parkour, ainda mais.

Então, eu não ia falar diretamente do parkour, mesmo que muitos dos pensamentos que eu queria escrever aqui surjam dos meus questionamentos em relação ao parkour. Mas daí o meu último post era sobre eu falando de como, após dois meses, tudo era ainda muito novo. E eu olhei um esquemazinho que fiz na época, uns rabiscos tentando ilustrar pra mim como é uma precisão, e vi que na época eu entendia errado o movimento, e consegui ver isso porque uns dois ou três meses depois daquele post eu tava ainda treinando precisões e de repente o corpo fez a coisa certa, e consegui, mais do que entender, sentir que estava certo. Ou mais certo do que até então. E aí pensar em tudo isso me puxou de volta pra questão do parkour, mas de um jeito assim, aleatório, trôpego, tergiversante. Acho que isso é fruto de eu precisar pensar, e precisar escrever. Seja como for, reconheço que foi legal olhar pro desenho e ver que aprendi algo, de fato, nesses 6 meses. De um jeito que me parece muito mais lento do que a maioria das pessoas que chegam nessa prática, mas aprendendo. O pior seria estar parada no mesmo lugar…

Precisões: agora ligeiramente mais precisas

Precisões: agora ligeiramente mais precisas

E.. enfim. Agora perdi o fio da meada. Mas ao menos termino o texto com uma sensação de que, se a gente não para, eventualmente muda de lugar.

Personal Shared Povs – reflexões

Ok, ainda não apresentei o projeto. Mas preciso comentar/ guardar isso em algum lugar: tenho de começar a pensar em como trabalharei os temas no dia anterior, do contrário corro o risco de não ter a luz adequada para as ideias que tenho…

[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: 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.

[LaTeX] Inserir nota de rodapé em legenda de figuras

O título mais apropriado para essa postagem seria – Inserindo notas de rodapé em ambientes float. Mas creio que esse que coloquei é mais legível e também funciona, já que no meu caso eu precisei para o ambiente de figura, mesmo.

O problema aqui é: o ambiente como \begin{figure} (por exemplo) é flutuante (float), não tem posicionamento fixo no LaTeX. Isso significa que… where you type is not necessarily where you get. Então uma figura pode ir parar em outra página, por exemplo, por falta de espaço. Mas se ela tem um rodapé, como o espaço para rodapé é outro, o rodapé às vezes acaba ficando na página anterior à figura, se houver espaço na página. Ou, como estava acontecendo comigo quando eu comecei a tentar resolver o problema, sequer aparece, pra começo de conversa.

Fazer o quê, em um caso desses? No TexExchange há várias respostas, especialmente nesse post. Mas nenhuma resolvia bem meu problema. Hora a figura toda ia parar fora de lugar (caso do uso do comando \afterpage, coincidentemente citado lá pelo Bruno); ou a nota ficava na página anterior (como comentei); ou nota e figura ficavam no lugar certo, mas a numeração da nota de rodapé ficava errada. Juntando uma das soluções que aparecem no no post que citei ali em cima, com a de outro post, cheguei à seguinte solução:

\renewcommand\thempfootnote{\arabic{mpfootnote}} % use números arábicos

\begin{figure}
  \begin{minipage}{\textwidth}
   \setcounter{mpfootnote}{1} % mostre números a partir de 1, não 0
    ...
   \caption{Caption\footnotemark.}
   \footnotetext{Foot notes}
 \end{minipage}
\end{figure}

Desse modo, consegui figura e nota de rodapé na mesma página, no lugar desejado, com a numeração coerente com o resto da monografia. Yays! Também postei essa resposta no TexExchange.

Redução de Escopo, Priorização, Correção, ou Priorização, Correção, Redução de Escopo?

Não é um jogo de palavras, tampouco um trava línguas. Ao menos, não só. Mas tenho de pensar rápido, para que não se torne outro trava-tcc. Qual a questão? Eu decidi que irei realizar as melhorias em apenas uma tela do sistema, que seria escolhida a partir do levantamento da quantidade de problemas por interfaces (tendo como base os resultados das avaliações heurísticas).

Certo. Acabo de fazer esse levantamento. Confirmando minha intuição inicial (no anteprojeto, o escopo do trabalho era esse), a Página de Resultados concentra o maior número de problemas. Somando todos os problemas encontrados e dividindo a quantidade de problemas encontrados em cada tela pelo total (esse racional faz sentido? parece-me que sim), a Página de Resultados (~44% dos erros encontrados) tem quase 15% mais problemas do que o Portfólio (~29% dos erros), segunda interface com mais problemas. Está decidido que focarei nela para a correção dos erros.

Mas, o que faço com as outras interfaces? Não posso abandoná-las de todo, ou corro o risco de continuar com problemas que impeçam os usuários de seguir o fluxo dos testes. Parece-me que o razoável aqui será observar erros que fazem o sistema quebrar (por exemplo, erro na busca de endereço), até que chegue à página de resultados, ou seja, erros graves na Página Inicial (~15% dos erros). Ok, creio que consigo me sentir tranquila com esse caminho…

Falta fazer amanhã (lol, o dia tem 36 horas? 56? Acho que vou precisar):

  • definir erros a corrigir;
  • corrigi-los;
  • formular e construir questionário de entrada;
  • formular e construir questionário de saída dos testes de usuário;
  • formular roteiro do teste;
  • testar roteiro;
  • verificar se precisarei instalar alguma ferramenta na máquina;
  • decidir se usarei Windows ou Linux.

Amanhã é um grande dia. Sábado também. Talvez todos, acho, daqui até o fim dessa jornada…

Eureka – Escopo, escopo, escopo! – Reduzir para conquistar

Então eu continuo travada, como os últimos episódios da novela já contaram, na compilação dos problemas da avaliação heurística. Eu já havia pensado que precisava, além de priorizar os problemas, filtrá-los, para saber o que faz parte do escopo do projeto ou não. Quando comecei a fazer essa atividade, me dei conta de que, logo no início, eu havia me planejado para trabalhar apenas com a tela de listagem de resultados – que é conhecida como SERP – Search Engine Results Page, porque tinha uma sensação de que era o ponto do sistema que mais concentrava problemas.

Em algum ponto no meio do projeto isso saiu de meu foco, creio que porque decidi que valia a pena considerar o sistema como um todo, para posteriormente, a partir dos resultados das avaliações, decidir o ponto mais interessante a atacar. E, agora, na medida em que percorria a longa lista de problemas, me parece o momento ideal para voltar a essa ideia. Então, vou aproveitar que destaquei os pontos do sistema que apresentavam cada problema para avaliar qual tela está mais crítica e elegê-la para meu estudo de caso.

Além disso, enquanto escrevia também me lembrei que o principal da avaliação heurística ser feita antes dos testes de usabilidade é evitar que os usuários se deparem com muitos erros, que poderiam atrapalhar o andamento e o propósito original dos testes. Então, posso nessa etapa focar em corrigir os erros que atrapalham o fluxo de uso e, posteriormente, quando for atacar a interface a partir dos feedbacks da primeira rodada de testes, atacar coisas mais sutis como organização de informações, espaçamento etc. Isso também me permite ganhar tempo para que as pessoas façam a classificação dos problemas, já que não preciso ter essa informação, necessariamente, para corrigir os erros mais graves, mas ainda poderei usufruir dos benefícios da classificação na fase de realmente propor melhorias para a interface. Além disso, definindo apenas uma tela, a listagem de problemas também se reduz… *-*

Que. Bom. Ter. Pensado. Nisso. /respira aliviada. Acho que finalmente vou desempacar. /o/

Acho que até consigo dormir, agora.

Compilação dos Problemas de Heurísticas: a volta dos que não foram

Como ainda estou brigando com a maldita etapa das Avaliações Heurísticas, acho interessante compartilhar um aprendizado breve para quem está planejando realizá-las.

O que torna especialmente interessante trabalhar com especialistas nessa forma de inspeção, ou no mínimo pessoas que tenham as heurísticas mais claras na cabeça, é que elas conseguirão se ater com mais facilidade ao escopo da avaliação e apontarão problemas de violação de heurísticas, de fato. Isso torna a posterior compilação muito mais simples – do que está sendo pra mim neste momento, em oposição, já que eu não tenho prática ainda com as heurísticas e, desse modo, não percebo rapidamente onde cada problema se encaixa ou, por vezes, se uma coisa observada é uma violação de heurística ou uma funcionalidade interessante de constar…

EDIT: ou talvez eu só tenha estimado terrivelmente mal o esforço envolvido nessa tarefa…

Avaliação dos concorrentes

Há um tempo atrás estava em dúvida em relação a qual a melhor abordagem para avaliar os concorrentes. Na época já me parecia que as avaliações heurísticas não seriam o caminho.

Ainda assim, até hoje essa tarefa está lá no cronograma. Hoje, como a revi, pensei mais uma vez no assunto. E realmente, para o que quero, não faz sentido comparar e avaliar os concorrentes a partir dessa abordagem. Eu quero saber o que os concorrentes provêm em termos de funcionalidades e facilidades para os usuários, não quem tem mais problemas… Logo, avaliação heurística para concorrentes is no more.

Será que alguém precisa rever e atualizar alguns pontos de sua metodologia? >.<‘

Avaliações heurísticas – andamento e aprendizados

Quase no fim das sessões de avaliação heurística (esta semana foi reservada pra isso). O processo é legal, e teve dois pontos interessantes:

  1. Pessoas de áreas distintas. Convidei, além de pessoas com formação em Sistemas de Informação, dois Designers. Além do fato geral de que pessoas diferentes trazem olhares diferentes, obtive feedbacks mais específicos de estética que achei bacanas;
  2. Para me adequar à realidade dos avaliadores e não gastar muito tempo deles ou meu, a maioria das sessões foram remotas (apenas uma foi presencial, até o momento). Dessas, muitas foram acompanhadas sincronamente via alguma ferramenta de video conferência / chat por voz, e uma foi feita sem acompanhamento. Uma foi realizada presencialmente. Isso me permitiu ter uma ligeira noção de vantagens e desvantagens de cada abordagem. Da experiência, creio que optaria por sessões remotas com think aloud e conversa por voz. Dão mais espaço para o avaliador (e talvez usuário, até) se sentir mais à vontade, mas contam com a vantagem de acompanhar o processo que os leva a cada conclusão, o que permite entender melhor os pontos que levantam.

Acabei optando por seguir um modelo em que os avaliadores indicam os problemas, e eu posteriormente os categorizo, dentro das heurísticas. No processo de categorização, estou sentindo falta de acrescentar duas:

  • onboarding: sistemas devem ter baixa curva de aprendizado e interface intuitiva, especialmente se forem ferramentas com funcionalidades de algum modo inovadoras / incomuns;
  • estética: interface deve ser agradável e não cansativa ao usuário (por exemplo, não usar muitas fontes, ter contrastes corretos). Isso me parece diferente da heurística de design e estética minimalistas. Preciso pesquisar e/ou falar com os orientadores a respeito, para decidir o que fazer.

O roteiro evoluiu na medida em que as avaliações ocorreram, principalmente as primeiras. A moda de duração das sessões foi cerca de uma hora. E, de minha observação, os avaliadores tendem a notar mais problemas quando fazem a inspeção conversando com o observador.

Amanhã e sábado talvez acontecem as sessões de avaliação com os orientadores. Espero conseguir fazer ao menos com um deles, para mim enriqueceria bastante o trabalho. Depois das sessões concluídas, farei uma única lista com todos os problemas levantados, para que todos os avaliadores possam lê-la e avaliar o grau de severidade de cada problema, utilizando a escala com 5 níveis de severidade. Estou pensando em usar o google forms pra essa etapa, tenho de testar a legibilidade do resumo de respostas.

EDIT: esqueci de comentar, mas o processo das avaliações me fez pensar que preciso repensar o agendamento pros testes de usuário. Aspectos de tempo, de como farei pra encontrá-los etc. precisam ser melhor pensados.