Reflexões sobre bikes e convivência – no asfalto e fora dele

Eu vejo um vídeo de um motorista de ônibus agredindo a um ciclista, depois de os dois se desentenderem no trânsito. O motorista, com o que parece ser uma barra de ferro, bate na bicicleta, principalmente. Várias vezes. Então ele se afasta, e o ciclista pega e decide que vai entrar no ônibus com a bicicleta (para acompanhar o motorista até a garagem e prestar queixa? para garantir que não deixará escapar a informação de quem fez aquilo com ele, caso o veículo vá embora?). Cobrador e motorista usem-se para expulsá-lo do ônibus. Novamente, de forma agressiva.

Nesse momento outras pessoas da rua (além da que filma) começam a ir pra cima, para intervir e evitar que a situação se agrave. Obviamente todos os ânimos estão exaltados.

O trânsito fica bagunçado, as pessoas ficam bagunçadas.

Eu pedalo pelas ruas de Salvador com alguma frequência. Já pedalei um pouco por outras cidades – Porto Alegre, Criciúma e algums próximas, Pelotas, subindo o litoral norte aqui na Bahia, Sófia, Barcelona. É impossível dizer que nunca vi atitudes claramente agressivas de motoristas contra ciclistas. Contra mim.

Mas também é impossível dizer que nunca vi atitudes agressivas e irresponsáveis de ciclistas – muitas vezes, compartilhadas em vídeos como se fossem sinônimo de liberdade e.. não sei o que mais – furar sinal com pessoas atravessando na faixa, passar de forma irresponsável em espaços muito estreitos entre carros, passar em alta em lugares de saída de carros. Ser desrespeitosos com pedestres que estão na ciclovia (qualquer semelhança com situações paralelas não é mera coincidência).

E também já vi muitos motoristas sendo gentis e atenciosos comigo. Já fui cumprimentada por cobrador de ônibus que sempre passa quando estou indo pro trabalho de bike. Já fui “escoltada” em cruzamentos mais perigosos. Tive a sorte de, nas duas vezes em que caí por conta de motoristas desatentos, eles pararam para ver como eu estava e prestar socorro.

Tive o azar de já levar fino de ônibus. MUITO fino. Tive a tristeza de ser cortada por carrão me xingando. Passei raiva com pedestre me zoando por eu passar apitando em ciclovia. Passei sustos absurdos por ciclistas virem na contramão e não saírem, mesmo me vendo. Ou por, pior – jogarem a bike em cima de mim, mesmo sem necessidade.

O trânsito – na ciclovia ou no asfalto – é lugar de convivência. E a boa convivência – pasmem – é resultado de um conjunto de fatores. Respeito. Cuidado. Compreensão. Atenção. Responsabilidade. Acolhimento. Reconhecimento.

Não acredito que motoristas são especialmente seres piores do que ciclistas. Porque continuam sendo pessoas. E porque, como disse, vejo muito ciclista fazendo muita coisa bem ruim. Acredito, por outro lado, que motoristas têm aprendido ao longo de décadas que o asfalto é lugar deles. E que, em uma sociedade que NÃO ensina a conviver e NÃO ensina a compartilhar espaços… Todos nós não sabemos conviver, nem compartilhar espaços – é só ver como muito ciclista age com pedestres ou outros carros, quando está em situação de vantagem, para vermos que todos padecemos dessa habilidade de deixar o que consideramos ser direito apenas nosso nos subir à cabeça.

Apesar de entender que as bikes são MUITO mais frágeis do que quase todos os outros elementos do trânsito – ou talvez por isso mesmo -, NÃO acredito que nos tornarmos mais agressivos, ou criarmos uma visão de que motoristas são iminentemente nossos inimigos, irá nos ajudar em algo.

Mais uma vez, e novamente, desconheço a habilidade do aumento da segregação para construir pontes.

Vou continuar achando que a saída não é ver motoristas como inimigos. Acho que estamos deixando de ver elementos importantes dessa “disputa”, se enxergamos as coisas desse modo…

Ritmo, disciplina, recuperação, frustração…

Um ano de parkour, e continuo nos seis meses.
Quiçá antes…

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…

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

Prototipando SERP e Document Surrogate

Passei os últimos… Dois dias? Talvez isso, talvez três, me sentindo meio empacada na Página de Resultados. Me sentia andando em círculos, ou desfocada, ou perdida, ou tudo junto. Cheguei a rascunhar:

Acho que… mexer no html direto às vezes faz perder o tempo e me desfoca. É possível que isso seja porque desvio de planejamentos, e fico apenas experimentando, sem metas claras. Os objetivos precisam ser claros, do contrário dá pra passar muito tempo mexendo semi aleatoriamente em interfaces e elementos =x

Ontem ficou evidente que eu precisava mudar alguma coisa na abordagem, pois o tempo está se esgotando e preciso ter alguma versão da Página de Resultados. Uma versão meia-boca me ajuda, pois posso prosseguir com as outras atividades e terminar o TCC em tempo. Nenhuma versão me leva a lugar algum e coloca em risco meu cronograma, de modo perigoso. Então decidi tentar escrever não apenas as correções que queria fazer, mas o meu objetivo pra página, ou tudo o que queria fazer nela, e em que ordem fazer, e quando usaria que ferramenta – para evitar, como comentei acima, ficar vagando pelo HTML.

Isso de algum modo ajudou. Ainda gastei um tempo danado, e me enrosquei um bocado até conseguir perceber que estava avançando. Mas, no processo, me dei conta de outra coisa que também deveria estar influenciando minha dificuldade com essa etapa e essa página – de algum modo, acho que sinto que essa é a culminância da parte prática do projeto.

O que me fez querer trabalhar com a usabilidade do fazDelivery foi justamente a página de resultados da ferramenta. Os itens de resultado espalhados etc, me incomodavam e eu queria mexer naquilo. E então trouxe isso para o TCC e desde o anteprojeto indiquei que o objetivo principal seria melhorar a SERP do FD. Então entrei de fato nas etapas do projeto, fui seguir os passos formais de resolver problemas de interfaces e muitos meses se passaram. rs. Referencial Teórico, Planejamentos, Adaptações, Cronogramas, Reduções de Escopo, Sessões de Avaliação Heurística, de Testes com Usuários, compilar todos os dados que daí surgem, ver os problemas que as pessoas apontaram (ao invés de sair mexendo a partir do que eu gostaria), mais reduções de escopo… E tudo isso “de repente” finalmente me leva para o que eu queria fazer lá atrás.

Ufa, ok, então, que houvesse tanta ansiedade no resultado dessa tarefa específica… Tudo isso só aconteceu porque queria fazer algo legal aqui. rsrs. Bueno, ao menos me sinto aliviada porque consegui ultrapassar as barreiras e entender quais eram, e elas faziam sentido.

Post its, ativar! Como ter uma comparação "rápida e simples" de posições de elementos de vários sites.

Post its, ativar! Como ter uma comparação “rápida e simples” de posições de elementos de vários sites.

E o que saiu daí? Fiz duas versões de Item de Resultado (Document Surrogate), tentando separar as informações do estabelecimento das informações do produto, deixando o item como um todo mais compacto e tentando dar mais destaque para algumas informações (além de tirar algumas coisas que pareceram não estar fazendo muita diferença, nos testes com usuários).

Tenho uma versão semi-pronta da página de resultados, que estava esperando ter resultados para irem nela. Fiz análises do Google, GuiaMais, iFood e TeleListas, para comparar onde posicionavam a opção de refinamento de busca (e como a apresentavam), além de quantos resultados exibiam antes da dobra (above the fold), e como estavam centralizados na tela. Usei isso para basear minhas definições de novo layout da SERP do fazDelivery, sempre colocando como restrição pra mim que eu focaria em trabalhar com os elementos já existentes, evitando criar funcionalidades ou elementos novos, e me guiando pelos resultados das avaliações heurísticas, testes com usuários e priorização de problemas que decidi.

Agora preciso encaixar a Busca Avançada na Página de Resultados, resolver Botão de Voltar ou Breadcrumbs – em suma, oferecer uma solução de Controle de Navegação -, e creio que a SERP estará pronta. Aí fica faltando a Página de Listagem de Categorias, na qual já dei uma pensada, e que será mais simples, uma vez que o item de resultado já está pronto.

Bueno! É isso! Vou dormir e voltar pra terminar essa parte. Ainda há um tanto razoável de coisas a fazer e depois precisarei descrever tudo mais formalmente, na mono. E ainda tenho de revisar tudo.

Woooo!

Estamos, meu bem, por um triz para o dia nascer feliz.

[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…

Reflexões: escrever aos poucos, ao longo do processo

O fato de eu ir escrevendo na medida em que vou decidindo o que fazer, mesmo que por vezes me faça pensar que estou evitando entrar em algumas tarefas, geralmente me ajuda a refletir muito mais sobre o que estou fazendo, de modo que consigo entender mais o que estou planejando, e tenho mais chances, assim, de avaliar se estou fazendo a coisa certa, tomando as decisões certas, seguindo o caminho certo…

Ou, mesmo que eu não consiga seguir o melhor caminho, ao menos eu posso tentar entender por que não estou seguindo. Se a justificativa for razoável, então eu sigo (:

Exemplo desse processo, hoje: mais cedo, comentei que começaria a prototipar hoje. Entretanto, no processo de analisar como iFood, GuiaMais e TeleListas resolviam as coisas que estava com problemas no fazDelivery, gerei umas tabelas que queria passar logo pro LaTeX. Quando fiz isso, percebi que precisava reestruturar o capítulo sobre prototipação, para encaixar cada coisa em seu devido lugar e dar uma noção da ordem lógica que segui. E, quando fiz isso, percebi que eu não podia já ter proposto soluções antes de ter olhado os concorrentes – mas foi o que aconteceu. Então, amanhã vou revisar as soluções que tinha proposto, comparando com as das outras ferramentas.

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.