O debate pegou fogo mais uma vez na FB… Foi só falar em “Flex para website” que estamos indo para os 50 replies. O caso é que a argumentação mais eloquente foi do Beck Novaes, que, apesar de não ter participado do debate, parece ter (finalmente) colocado um ponto final nesta (aborrecida) questão.
Maps: could they be easier to use? Download the english version.
Este é outro post sobre usabilidade, e, mas i uam vez, o tema é o musue virtual que eu estou ajudando a projetar. Ele tem uma rolagem 2D horizontal, de forma que o usuário pode rotacionar a sala e ver as imagens. Este tipo de navegaçao é bem conchecido, por isso não epsero que haja dificuldade.
As sals têm mapas, mostrando a planta de cima, como numa planta baixa, o que também é bem típico. Mas eu estava me perguntando: quem deveria rotacionar? A sala ou o observador? Abaixo há exemplos dos dois casos:
Figura 1. Preesiona play para ver o observador rotacionando, e a sala se mantém fixa.
Figura 2. Pressione play para ver a sala rotacionando, enquanto o observador se mantém fixo.
A favor da opção “observador rotaciona – sala fixa”, temos os argumentos:
A desvantagem é:
Par o mapa alternativo (“sala rotaciona – observador parado”), a vantagem é:
Os contras são:
E você, o que acha? Quala melhor opção e porque? Qualquer que seja resposta,a lição é esta: você deve sempre tentar melhorar seus controls de navegação. Como se faz isso, é assunto pra outro post.
Using opacity in navigation. Download the english version.
Post rápido :0)
Estou projetando a interface de um museu virtual, que vai tre uma mostra de Mineralogia.
E eu tenho uma “queda”, uma preferência pessoal por “alphas”, imagens com um grau de opacidade. Para quem não sabe o que é, são imagens translúcidas, semi-transparentes.
Mas elas parecem não estar “funcionando” no meu principal, ainda wu estajm bem no menu de scrolling…
O caso é que, no menu de scrolling (a imagem mais à direita),a opacidade permite ver o que está embaixo do botão. Isso é importante porque a tela rola embaixo dele, de forma que pode ser que tenha uma imagem ali. Também está funcionando bem para controls que mostram o nome de uma determinada imagem, quando se deixa o maouse sobre ela (também conhecida como data tip)
A vantagem deste efeito se perde no caso do menu principal: debaixo dos botões sempre tem a mesma coisa: uma faixa preta. Quando o menu se abre (como na imagem mais à esquerda), não irá ficar aberto por muito tempo, e enquanto está aberto, você não se interessa pelo que está embaixo. Além do mais, como o que está embaixo varia conforme a sala gira, os botões do menu ficam com um fundo diferente a cada vez que abrem…
Bobagens pseudo-cognitivistas, você diria. Sim, mas está “quebrando” a aparência dos botões… Memso um nvato sabe que os controls de uma apliação devem ter uma alto grau de coerência, ou seja: eles se parecem e se comportam da mesma forma, para que o usuário possa prever o que via acontecer quando interagir com o control.
Contudo, como as transparências estão mesmo atrapalhando no caso do menu, vou removê-las dali, e manter nos demais controls.
Adeus aos botões com alpha…
:***(
I have – as lots of people do – the “intuition” that designers shouldn´t design alone: we should be followed closely by our engineering counterparts. This is something pretty easy to stand for – as long as we´re on paper (or on screen, as is my case).
It´s no secret that we don´t get along well: we don´t agree, don´t trust and sometimes we dislike each other. If you could hear engineers talk about designers and vice versa (add architects x engineers; digital designers x coders to the tale) and you´ll get the picture.
Oh, but well, as I said: it´s not a secret. And I will not bother to talk about something everyone knows.
I´ll talk – briefly, because I have an UI to specify :0( – about something concrete: a case were a design decision was supported by an engineering constraint. I think this is important because when we stand for interdisciplinarity (I hope this word exists) – in front of less experienced co-workers or students, as is my case – we should have examples of what we´re saying.
I´ve been advocating for interdisciplinarity inside the teams I work, and I think it´s been a valuable experience, but the concrete knowledge of why is it that good sometimes is missed or shared as a valuable (though not easy) experience. Maybe it´s because of my professional background experience – I am a designer, an human factors specialist AND a coder. I feel the bitter and the sweet of being in all those fronts.
So, as I was saying, I am detailing an UI. It´s going to be a car pool software, for the university I work for. I stated we should have callouts to represent the passengers. The idea is that the driver, after placing a route, will see all the people he could pick up. Those people would be represented as callouts. When the user-driver passes the mouse over the callout, it´s going to expand, showing the name of the person. When the user clicks the name, the callout expands once more, to show a button asking if you accept the passenger. If you do, the callout will show a picture and contacts of that person.
Pretty well. So, drawing, I made the callouts rectangular. Why did it do that?
But this shape has a problem. Can you spot it?
I couldn´t untill I started writting the use case for the “system actor” called “Retrieving passengers”. What did I found out? Placing assymetrical callouts over the route would require aditional logic. Each callout would have to “know” the best position: turned left or ritgh; upside down or heads up.
I only realized it when drawing: how would I ask for the devs to work this out?
So turned me back to google maps callout. I found them ugly and uninteresting. But they are much easier to place. They do not need that extra work.
Now the questions are:
My answer – based on my knowledge as design and coder – is: the differences are not that relevant and the logic is really difficult to implement.
So this decisions poses another issues:
In this figure, you see the green “circle like” callout (which is a google maps callout) representing a point the user-driver set in his rout – he IS going to pass that spot. I stated that because sometimes you are not willing to take the route the computer advises to: you have to pick up you sister in her work, you´re going to cash money, you think the best route is not the faster, it could be crowed and the list goes on and on. That´s why the user-driver will have the freedom to specify the route. And maybe he will like to see if a passenger is near a place he is going to pass by. You have to remember that maybe the driver dont know the passenger, so, I could be an additional aid for him to know that: Ill be picking Sonia near that street / avenue / place.
So, thar leads me to a dead end… I cant tell whats more important. I realized the trades I have to make, but I think I dont have enough information to make a decision. So, what will I do? I will specify the harder-to-do-callouts, which will solve the interaction problem – I think – Ill have if they are symetrical (as google´s), and ask for user tests on this feature. If it´s really necessary – if Im right – we´ll have the budget. If it´s not, my dev team will be pleased with me worring for not to waste their time.
So, to finish, I made a picture showing the pathway from the problem discovery to the solution specification.
Então tá. Terminei meu programa sobre carros. Agora, se você, como eu, não consegue escolher qual o melhor carro pra você, use este programa, hehe.
Bem, claro que a maioria das características não está implementada… Só tem ano de fabricação e consumo… Mas, vamos combinar, o resto é moleza!
Quem for olhar o programa e dizer que está feio porque não segue MVC, eu digo: isso era só pra fazer o programa funcionando… Não pretendo mexer nele de novo… Até porque, eu não gosto de mexer em programa velho… Pior que comer feijão frio (sei que tem gente que gosta, mas… eca!).
Enfim… está tudo comentado: quem quiser ver como faz essa coisa bonitinha de drag n drop é só baixar / instalar e procurar a pasta srcview dentro do seu micro. Ou então clique aqui para ver o source da versão AIR…
Me diverti fazendo isso…
O programa é para AIR. Para quem não sabe o que é AIR, é um runtime que permite fornecer facilmente um único instalador de aplicativo que funcione em todos os sistemas operacionais (pra fazer os arquios feitos no Flash e no Flex serem instalados como um programa no seu Desktop e poderem acessar o sistema de arquivos, o clipboard, o system tray e outras coisas que não podemos acessar no browser).
It´s all about the task. Download the english version.
Estou envolvida com um projeto pessoal, cuja motivação foi a dificuldade que estou passando para escolher um carro novo. Muito complicado para quem não é expert. Até agora estou com a sensação que não fiz a escolha certa. Então, o projeto que propous a mim mesma: como eu poderia criar um software que poderia realmente ajudar as pessoas a escolher um carro?
Todas as minhas dificuldade forma causadas pela forma como a informação é disposta. Os sites onde você busca opções (como, no Rio Grande do Sul; sul do Brasil, www.autocarro.com.br ewww.panambra.com.br) não ajudam você em nada. Esses sites de revendas, por exemplo, mostram diversos dados sobre os carros, todos ao mesmo tempo… Mas e daí? Eu não pretendo formar uma base enciclopédica de conheciemtno sobre carros. Eu apenas quero saber qual o melhor carro para mim.
Veja as imagens abaixo.
De um ponto de vista cognitivo, o que precisamo fazer?Precisamos percorrer toda a lista, armazenando um dado (digamos, preço), e comparando com o seguinte. Se o carro seguinte tiver um preço melhor, substituimos o anterior pelo atual. E assim até terminar a lista. Se dois ou mais fatores são igualmente importantes, precisamos computar a razão entre estes fatores. Se dois ou mais fatores não são igualmente importantes, fica mais difícil. Aliás, acho que não conseguiríamos tratar este problema, usando apenas a cabeça… E se nossos recursos ($$) não compram o carro que queremos, precisamo abrir mão de algumas coisas (diração hidráulica? rodas de liga?). Mas do que?
Entenderam? Talvez eu seja meio neurótica… Mas eu queria fazer a escolha certa, e não desistir do problema e comprar qualquer coisa.
Bom, o caso é que parece que ninguém se preocupa com isso… Todos os designers parecem ter colocado em nós – usuários indefesos e cognitivamente limitados – a carga de armazenar, computar e comparar listas intermináveis de itens. Claro! Nós humanos somos ótimos com isso…
Alguns exemplos de jogos, começando com Grand Turismo 4 (PS2). Eles são todos baseados no mesmo princípio: você conhece os carros. Se não, então você terá que lembrar de todas as características e comparar com o próximo carro da lista. A segunda imagem logo abaixo, mostrando um modelo da Chrysler, é um exemplo deste visão: você pode ver algumas imagens, e, na parte de baixo, uma lista de características. Além disso, GT adiciona uma dificuldade inesperada: você tem que saber qual a comntadora do carro. Ok, você está num jogo de corrida, então espera-se que você conheça carros. Mas estou analizando de um ponto de vista do design da tarefa. Para um usuário comum, isso aumentaria a dificuldade em realizar a tarefa.
Veja esse exemplo do Mário Kart (MK).
Entende o que estou dizendo? A aparência está ok, é legal (na minha opinião, poderia ser melhorada, quero dizer, porque aqueles volumes e gradientes esquisitos, as listras grandes e com volume e aquele troféu 3d cromado??), um pouco fora de moda. Mas, de qualquer jeito, o problema ainda está la: qual o melhor carro pra você?
Eu perguntei pro meu filho (11 anos) como ele fazia pra escolher o carro, e ele disse que simplesmente testa todos até encontrar o que ele mais gosta. Se você argumentar que os designers do MK tiveram essa intenção, que eles deliberadamente tornam difícil achar (descobrir) o melhor carro só pra você jogar mais, então ok. Mas eu ainda acho que é um equívoco de design de interação.
Sabe o que eu penso? QUAL É A TAREFA???
A tarefa, você pode dizer, é escolher um carro. Mas quais são os passos que você provavelmente irá percorrer até chegar à resposta: “o melhor carro para mim é …”. No meu ponto de vista, esta é a verdadeira questão. Uma possível resposta seria:
Agora acho que a coisa foi alterada … Você vê, em vez de “qual é o melhor carro para mim”, a questão é “qual carro tem a melhor razão entre as funcionalidade , considerando que tenho uma restrição (dinheiro) e que algumas características são mais importantes do que outras”. Uau! Muito mais difícil!
Então, vamos passar à tarefa. Suponha que você tenha a pior interface em todo o mundo, ok (este é um grande exercício!)? Eu proponho que você tem uma interface com cartões que representam todas as possíveis características listadas. Embora os cartões estejam “soltos”, ou seja, não ligados ou agrupados por qualquer meio, os recursos são enumerados em ordem alfabética ou categórica (por isso a pesquisa no cartão seria mais fácil);e da mesma forma por todos os cartões; utilizando uma fonte com boa legibilidade e tamanho; o cartão teria muita contraste com o texto. A interface também teria botões “próximo” e “anterior”.
Permita que o usuário utilize esses cartões para escolher. O que ele faz? Acho que ele iria responder às três primeiros perguntas (a quarta seria necessário se as limitações impõe grandes restrições à escolha, de modo que o usuário teria que pesá-las novamente). Portanto, vamos segui-lo:
As respostas são
Ah … Essa é uma tarefa difícil para os seres humanos. Nossa mente não está preparado para fazer os passos 5 e 6 desta sequencia! Como é que vamos fazer este cálculo? Como vamos armazenar montes de dados?
Outra dificuldade é que esse processo supõe que o usuário tem livre acesso e controle de sua STM … Sim, certo …
Então, vamos voltar ao nosso estudo de caso interfaces: “www.autocarro.com.br“, “www.panambra.com.br” e MK’s. Como eles ajudam os nossos pobres usuário equipados para fazer a tarefa?
Autocarro
1. Mostra todos os carros de um modelo (o usuário já sabe o carro para comprar!). Também mostra preço, ano e uma foto, com dados extra.
2. O usuário vê uma lista paginada
3. Avança através de 2 a 10 do nossa lista.
O “Autocarro” está assumindo: o usuário já sabe o carro para comprar.
Panambra
1. Solicita ao usuário a marca do carro (GM, Ford, etc.)
2. O usuário vê uma lista paginada
3. Avança através de 2 a 10 do nossa lista.
Que “Panambra” está assumindo: o usuário já sabe a marca que o carro deve ter.
MK’s
1. MK’s é, na verdade, o pior … É a nossa “pior-de interface possível”, com sombras e chromes …
Mas eu tenho notícias de um exmeplo excelente: Volkswagen´s used car locator, em http://www.volkswagen.co.uk/used/search
Você diz que carro prefere (baseado num conhecimento prévio, mas acho que está ok), e depois você adiciona restrições: quanto poderia custar? o que precisa ter? quais seriam a quilometragem e idade máximas? depois, você dá um CEP e busca. Ele traz todas as opçoes para você.
Que tal esse design? É meio que comlementar ao anterior, com a diferença que a aplicação vai dizer qual o melhor carro pra você, baseado na importância relativa que você acabou de atribuir.
Está feio, eu sei. Mas seria mais fácil escolher. Não precisa IA nem nada. Um algoritmo bobalhão.
Isso é design de interação.
Pra quem não entendeu, “não é bolinho” significa “não é fácil”. Este desabafo tem a ver com um fato que acabou de acontecer comigo (numa manhã de terça feira chuvosa em Porto Alegre) .
Estava eu trabalhando no Flex, construindo uma interface super bacana para um programa que estou fazendo. A idéia é ótima, olha só:
Daí? Bala, né?
Pois então, imagina que esse mapa aí atrás tem um navegador, zoom e pan, e que os balõezinhos acompanham o mapa à medida que tu interage com ele – cara! – e não aumentam de tamanho! Pois eu espremi o meu cérebro do tamanho de uma cereja e me saí com um super-método de transformação de coordenadas que não é uma gambiarra! Eu tava aqui me sentindo o máximo – tô aqui cheia de Matrix e Points e etc…
Bem, depois que eu finalmente consegui colocar essa coisa toda pra funcionar (tava pensando: acho que vou no cinema hoje de tarde), coloquei mais uns personagens no meu XML e…
Cinema?
Moral da história para programadores: UML? Não! Desenhe cada tela antes de começar. Faça cenários. Desenhe os cenários. Depois, só depois, UML. Esse erro vai me custar horas de planejamento do sistema. Só que eu não tenho tempo pra isso.
Moral dois (ainda para programadores): Quando vocês tiverem uma idéia bala e diferente para interfaces, mesmo que achem que saibam como implementar, dupliquem o prazo do projeto.
Moral três (é, ainda): Provavelmente os padrões vão salvar o meu dia (e com esperança o meu cinema, que talvez role um pouco mais tarde).
Moral da história para designers: não odeiem os programadores. Eles (a gente?) não consegue prever tudo.
Recent Comments