Se pretendemos melhorar ainda mais o produto que entregamos hoje, achamos conveniente repassar nossas premissas do projeto. E acreditamos que o site, na versão que se encontra atualmente, não está entregando todas essas premissas como deveria. Para a próxima versão do site, estabelecemos dois objetivos básicos, que seguem.

Vendemos não só código-fonte, vendemos uma filosofia.

Junto com o Zip de código, nosso projeto quer incentivar o desenvolvedor a adotar boas práticas de trabalho. Sentimos que nosso site pode melhorar bastante neste aspecto, a entrega dessa filosofia precisa ser mais explorada ao longo da navegação. O objetivo do site, no que diz respeito a ambiente de trabalho, é engajar os desenvolvedores a adotarem essa cultura de produtividade e diversão.

Precisamos dar o suporte adequado ao nível de conhecimento do desenvolvedor

Com o feedback inicial que tivemos desde o lançamento da primeira versão pública do Spaghetti*, de modo geral pudemos perceber dois níveis distintos de desenvolvedores que se envolveram com o projeto. O primeiro deles é o desenvolvedor que conhece pouco de programação e pouco sobre o funcionamento de frameworks e design patterns em geral. O segundo nível é o desenvolvedor que já absorveu os conceitos necessários e consegue encontrar todas as soluções para os problemas que encontra.

Precisamos, desta maneira, pensar no nosso suporte e documentação para contemplar esses diferentes níveis de conhecimento e experiência com as ferramentas. Para o usuário iniciante, precisamos reforçar o conteúdo didático, como guias do usuário e tutoriais. Já para o desenvolvedor mais avançado, precisamos expandir a documentação para abranger toda hierarquia do código, classes e métodos, oferecendo com detalhes a totalidade dos recursos disponíveis.

Branding

Apesar da controvérsia no nome, nossa marca tem sido aceita e entendida pela comunidade. As pessoas que se dedicam a entender o projeto acabam por absorver também um pouco da nossa filosofia de, sobretudo, diversão. Não pretendemos alterar nem esta filosofia nem nosso nome, porém está em estudo uma mudança na tipografia e na paleta de cores da marca, para refletir mais compromisso com a qualidade e, ao mesmo tempo, trazer a sensação de descontração.

Próxima etapa

Agora que já temos um mapeamento básico do que precisa ser melhorado, vamos começar a pensar em como, de fato, aprimorar o que foi listado acima. Para cada uma das questões, precisamos pensar em maneiras de como melhorar essa entrega e como melhorar a experiência em geral, para depois partir para o projeto na prática.

Colaboração

Queremos fazer deste processo de redesign um processo transparente, expondo o que é discutido para todos. Como sempre, contamos com a sua colaboração para nos dar feedback sobre o que você acredita que pode ser melhor. Não será um processo totalmente colaborativo, mas será transparente: manteremos registro de acompanhamento de todas as etapas do processo.

Explicamos que não será um processo totalmente aberto pois, apesar do input do usuário ser muito importante, certas decisões de design envolvem outras necessidades e interesses. Mas de qualquer forma, procuraremos atender as solicitações relevantes para tornar nosso produto e nossa entrega melhores.

Experiences can be found all over the place, but for scope purposes let’s focus on human-computer interaction. The user experience designer architects culturally relevant products with attention to, said Norman (1999), “all aspects of the user’s interaction with the product: how it is perceived, learned, and used”.

Creating a product that’s both easy to use and enjoyable demands acknowledge of a wide range of study fields, from psychology to visual design, passing through marketing, product design, usability engineering, among others. Psomas (2007) developed a framework that comprises the competences a UX designer or team should have, as follows.

Information Architecture

According to Psomas (2007), an information architect’s job is “designing a user interface (UI) structure that satisfies the corporate business strategy, product strategy, and user experience strategy and accommodates all use cases and product requirements”. Information architecture addresses questions such as “How do users move from place to place?” and “What rules exist that users have to work around?”.

The information architects delivers navigation patterns, information hierarchy and structure diagrams.

Interaction Design

The interaction designer creates the concepts of the artifacts and specifies the behaviour of the interactions in a system. It’s somewhat grounded to basic principles of cognitive psychology, involving the study of how individuals handle problem solving, memory and language.

The interaction designer delivers user goals, functional inventories, user requirements, wireframes and storyboards.

Visual Design

The role of the visual designer is giving consistent treatment of elements and components of an interface. Here comes the visual design theory, including color theory, typography, shapes, textures, sizes and the form psychology laws (Gestalt). The visual designer delivers mockups and style guides of interfaces.

Usability Engineering

Usability engineering is a field concerned with making human-computer interfaces highly usable, which comes to the accomplishment of tasks with both efficiency and efficacy. Some of the theoretical foundations of usability engineering are human cognition, percetion and behavioral research methodologies. An usability engineer delivers usability reports, findings, surveys, feedbacks, session recordings and usability recomendations.

Prototyping Engineering

Prototypes provide functional versions of interaction concepts. Since user interface (the presentational layer of an application) has became more and more separated from the business logic layer, prototypes are helpful to “alleviate uncertainty about design intentions, clarify functionality, and reduce the need for documentation” (Psomas, 2007).

Further reading and research references

NIELSEN, Jakob. Usability engineering. – Morgan Kaufmann, 1994.

UXMatters.com: Insights and inspirations for the user experience community. Available at: <http://www.uxmatters.com>.

NORMAN, Donald. Invisible Computer: Why Good Products Can Fail, the Personal Computer Is So Complex and Information Appliances Are the Solution. – MIT Press. 1999

PSOMAS, Steve. The Five Competencies of User Experience Design. Available at: <http://www.uxmatters.com/mt/archives/2007/11/the-five-competencies-of-user-experience-design.php>.Access date: Jun 28th. 2009

A experiência começa desde antes do primeiro contato com um produto, quando você ouve algo a seu respeito. Se você ouve pessoas falando mal do Windows Vista, mesmo sem conhecer e usá-lo diariamente, você já terá essa impressão que pode, em um futuro próximo, determinar se você comprará ou não o sistema. O livro mostra a preocupação de Jobs com todos os processos antes, durante, e depois da compra. Dos parafusos às embalagens, e até mesmo como os produtos se comportarão com os outros produtos que o comprador já possui.

Há uma característica marcante de Steve Jobs que eu enxergo em mim mesmo: a busca pela perfeição tanto nas interfaces quanto nas interações. Há designers e designers por aí. Mas eu preciso compartilhar uma coisa com vocês, que aprendi lendo uma porção de livros (inclusive A Cabeça de Steve Jobs): eu não sou um Web designer, sou um designer de experiência. Eu, como designer de interação e designer de interfaces (que são coisas muito diferentes) devo me preocupar não com contextos isolados de etapas de um processo, mas como estas etapas interagem entre si.

Ao estudar design de interação, comecei a me dar conta que os projetos de sucesso online e offline são aqueles que exploram não somente como as coisas são mostradas para um usuário, mas qual a seqüência de etapas que completam os processos e qual a melhor maneira de otimizar os vínculos entre estas etapas, pois é neste quesito que – mesmo subconscientemente – o usuário considera sua navegação satisfatória ou não.

A Apple, segundo o livro, não se preocupou apenas em desenhar uma boa interface de usuário para seu software de edição de vídeos: estudou como as pessoas utilizam suas câmeras de vídeo portáteis. Desde a captura até a edição. Deste trabalho de pesquisa saíram grandes novidades que mudaram o mundo da computação pessoal e a vida das pessoas. A Apple desenvolveu a interface Firewire, otimizada para fluxo de vídeo, o software iMovie para tornar a edição divertida e descomplicada e um computador – o iMac – que além de possuir a conexão Firewire e de executar o iMovie, tornava o vínculo entre a câmera e o software simples.

Desde então, a Apple tem se preocupado em oferecer experiências. Você não compra apenas um iPod: você compra uma experiência entre você, o player, o iTunes e o seu Mac. Tudo isto, claro, foi trabalhado para que você não se preocupe com estas etapas. Você apenas precisa plugar seu iPod e o resto o seu computador e o iTunes se encarregam. Embora haja certas limitações, é uma concessão que você fez em nome de um produto que simplesmente funciona.

E é aqui o ponto onde eu quis chegar. Eu considero importante para o meu trabalho como designer de interação e de interfaces avaliar o projeto para torná-lo “invisível”, para que o artefato guie o usuário para a realização da tarefa com sucesso sem que ele precise antes aprender a usar as interfaces.

O André Braz publicou em seu blog uma nota interessante sobre Interfaces de Usuário Naturais, citando o trackpad multi-touch de seu MacBook Pro. Os movimentos feitos correspondem às ações de maneira natural, orgânica, sem que o usuário precise decorar sequências de comandos. Este é o foco ao projetar uma experiência com interfaces Web: tornás-la tão naturais que virem transparentes, que estejam lá dando o suporte à execução da tarefa mas que não se tornem um fator condicionante. Pelo menos é assim que eu vejo o assunto.

Enfim, o livro é muito bom para todos os profissionais, pois mostra que não há espaço para desleixo, que todas as etapas do processo de desenvolvimento de um produto são importantes mas que não acaba por aí. Pelo contrário, quando você entrega um produto ao usuário, sua experiência está apenas começando.

Como eu disse, com o passar do tempo novos recursos e conteúdos estarão disponíveis aqui, e conto com o seu feedback para me ajudar a compor o meu novo design. Isso mesmo, você é quem  vai me dizer o que você gostaria de ver aqui, no espaço que ainda resta. São várias opções, últimos comentários, meu Twitter, algum widget como o do BlogBlogs, feed de outros blogs que escrevo, blogroll, categorias, tags, busca, enfim, o conjunto completo de buzzwords da blogosfera. Você pode colaborar e ajudar a escolher o que acontece por aqui.

Em tempo: usando criei uma rápida pesquisa, para levantamento dos widgets que vocês acham mais interessantes. Ao mesmo tempo que isto fica como uma pesquisa quantitativa e qualitativa, serve de modo geral como uma enquete para entender melhor sobre você. Mas não se preocupe, a pesquisa possui apenas três questões e não pede seu CPF nem seu cartão de crédito.

Desde já obrigado pela fidelidade e por acompanhar o blog. Em breve posto mais novidades sobre as mudanças no blog do Rafael Marin.

Lembre-se sempre: você deve entregar a melhor experiência ao seu cliente e ao seu usuário, sempre. O que ocorre muitas vezes é que com prazos apertados geralmente o programador é quem desenvolve a interface administrativa, ou ela acaba sendo deixada por último, e feita às pressas. A atual interface do gerenciador de conteúdo é pouco convidativa e confusa. O sistema possui muitas ramificações de conteúdo, e para isso, a atual interface propôs um sistema de navegação via dropdown menus que só complicam, pois não mostram de maneira clara a organização do conteúdo.

Além disso, na mesma barra de menus os desenvolvedores optaram por juntar opções referentes ao sistema em si com o próprio gerenciamento. Isto é, junto a opções como notícias, atas e boletins, encontravam-se opções como alterar senha do administrador ou efetuar logout. Com a proposta inicial de reformulação que desenvolvi, procurei resolver estes problemas e ainda deixar a interface mais agradável e convidativa.

Problema #1: a organização do conteúdo

Há bastante conteúdo no site do cliente, principalmente na área restrita aos colaboradores. A estrutura anterior, baseada em menus dropdown, não oferece ao administrador a clareza necessária e a agilidade para uma administração eficiente. Perde-se muito tempo procurando opções e tentando mirar o mouse sobre o item escolhido sem errar a pontaria. Nas opções do menu também haviam ícones pouco descritivos acerca do que cada opção representava.

Ícones, usar ou não usar?

Como quase tudo nesta vida, depende. Em sistemas administrativos onde a estrutura do conteúdo se refere a termos muito específicos, talvez a utilização de ícones consuma mais tempo e dinheiro do que traga reais benefícios aos usuários. Por isso, me restringi a utilizar ícones em contextos onde eles consegue realmente ajudar no reconhecimento da tarefa. Por enquanto, os únicos lugares que utilizei foi nos links no topo para opções e logout, já que seus usos e representações são amplamente conhecidos e, por isto, justificam a utilização de ícones.

Problema #2: administração do conteúdo vs. administração da administração

O que acontecia no painel antigo era que as opções do menu estavam mal organizadas. Não somente por sua estrutura hierárquica e por sua má apresentação, mas também por misturar tarefas referentes ao gerenciamento do conteúdo com tarefas referentes ao gerenciamento do sistema de gerenciamento, como cadastro de usuários, troca de senha e logout. A dica aqui é simplificar. Separe o que é específico das tarefas que envolvem o conteúdo do restante das opções. Assim você facilita para o usuário do sistema, removendo todas as distrações de seu caminho.

Utilize sim o apelo gráfico, mas com moderação

Há designers que, às vezes, colocam elementos tão ou mais chamativos que o site principal na administração. O que rege o sistema administrativo é o foco na realização das tarefas, de maneira fácil e sem distrações. Por isso, pense duas vezes antes de incluir Flash ou outros elementos que não agilizem a execução do fluxo administrativo. Isso não significa que você não deva se preocupar com o refinamento estético da interface.

Utilize uma linguagem gráfica simples, abusando dos espaçamentos e do espaço em branco, porém mantendo alinhamento coerente e uma cartela de cores suaves. Como qualquer outro sistema, seja ele desktop ou Web, a interface bem acabada e esteticamente agradável motiva o usuário a explorar os recursos que ela oferece e, de quebra, executar as tarefas desejadas com mais eficiência e rapidez.

Ofereça comodidades em JavaScript para automatização e simplificação dos processos em lote

Um benefício evidente do uso de JavaScript e de requisições assíncronas é tornar tarefas repetitivas mais simples, evitando redirecionamentos desnecessários. No nosso caso, em determinadas divisões do conteúdo, o cliente frequentemente apaga todos os registros para atualizar com novos, e então oferecer o recurso de selecionar múltiplos ou todos os itens ao mesmo tempo para apagá-los é outra comodidade simples de implementar, mas que faz total diferença no fluxo de trabalho.

Mantenha o usuário informado com feedback constante

Principalmente quando se usa bastante AJAX na página, é comum que o desenvolvedor esqueça de informar ao usuário o que está acontecendo, e se está acontecendo alguma coisa. Não esqueça de loaders que, por mais simples que sejam, já dão um bom motivo para o usuário aguardar e não achar que algo está errado.

Com relação aos botões, se você cria links que se parecem com botões, um pequeno detalhe que torna a experiência mais rica é adicionar os estados de quando o mouse está sobre o botão e quando o botão está sendo pressionado. Além disso, você pode aproveitar os botões também para fornecer um feedback imediato e prévio sobre as consequências de sua ativação. Nos botões de apagar, por exemplo, coloquei a borda e o texto em vermelho, para dizer ao usuário – com antecedência – no que o clique resulta.

Informe os usuários sobre o sucesso de uma tarefa ou sobre eventuais erros

É frequente vermos sistemas prontos, completos, que se esquecem completamente de informar ao usuário quando uma tarefa foi completada ou, o que é pior, quando um erro aconteceu. Este tipo de situação é previsível, pois muitos fatores podem acarretar em um erro, desde erros de validação de dados até erros no servidor ou na sintaxe do código. Por isso, escreva sempre mensagens de erro que não somente informem o que aconteceu mas, mais importante, como resolver o erro.

Seja produtivo: utilize a mesma (boa) interface administrativa para todos os seus clientes

Se todos os clientes de sua empresa utilizam o mesmo sistema de gerenciamento de conteúdo, ou mesmo dividem o mesmo framework de desenvolvimento, o que você pode fazer é utilizar a mesma interface administrativa para todos eles. Assim, todos os clientes terão uma boa experiência administrativa em seus sistemas on-line e você não precisará se preocupar com o desenvolvimento de uma nova interface a cada projeto.

Para finalizar, a mensagem é esta: não descuide da administração. Gerenciar é uma tarefa fundamental ao funcionamento de um sistema e tornar esta tarefa mais agradável ao seu cliente é lucro tanto para ele quanto para você. Espero em breve, com a evolução deste projeto – que está apenas começando, compartilhar mais sobre o processo de redesign que estou realizando na agência onde trabalho.

Modelos mentais referem-se à maneira com que utilizamos nossos conhecimentos já adquiridos para tentar adivinhar ou prever o funcionamento de determinado artefato ou aspecto do mundo físico. Este termo foi definido por Craik em 1943, no livro The Nature of Explanation. Os modelos mentais são frameworks conceituais (teorias) para a cognição, sendo amplamente estudados durante o processo de design de produtos interativos para compreender de que maneiras o homem entende, percebe, toma decisões e se comporta em frente a um ambiente ou tarefa.

São importantes para a usabilidade, visto que esta tem o objetivo de tornar as interfaces e a interação mais naturais ao homem. Quando falamos nesta naturalidade de manipulação, nos referimos diretamente aos modelos mentais envolvidos na utilização de um sistema de computação. Apesar de, na maioria dos casos, haver grande carga de aprendizagem a cada nova interface apresentada, com o passar do tempo e com a utilização de mais artefatos computadorizados o usuário desenvolverá modelos mentais mais aprofundados a respeito de interfaces interativas como um todo.

Porém, em diversas situações, o indivíduo utiliza modelos mentais de maneira errônea. Segundo Kempton (1986), citado por Preece (2005), as pessoas usam modelos mentais baseados em uma teoria geral de válvulas. Ou seja, quanto mais pressionar um botão mais o efeito esperado ocorrerá. Como exemplifica Preece (2005), isto é bastante comum com a operação de termostatos, ou de elevadores. Pressionar o botão do elevador diversas vezes ou com força não fará com que o elevador ande mais depressa, ou utilizar uma grande temperatura não fará com que um ambiente se esquente mais rápido.

Em interfaces de Internet ocorre o mesmo, por diversas vezes. O usuário, baseando-se em suas experiências anteriores com interfaces gera modelos mentais que às vezes não são supridos. O exemplo mais simples, e bastante ocorrente em livros conforme mostrado no livro Homepage Usability: 50 Websites deconstructed, de Jakob Nielsen e Marie Tahir (2001), é o de sites que ferem um dos elementos básicos da interface gráfica dos computadores utilizando gráficos com forma de botão mas que não são clicáveis. Neste caso, o resultado decorrente da experiência é frustração, visto que o modelo mental – e, diga-se de passagem, uma das metáforas de interface mais primordiais das GUIs – foi ferido com brutalidade.

Segundo Norman (2004), existe uma filosofia de design que utiliza metáforas de interface na formação de modelos mentais. Porém concorda que nem sempre esta é a melhor diretriz a ser seguida visto que, apesar das metáforas facilitarem o aprendizado, às vezes podem tornar a assimilação mais complexa, considerando que no desenvolvimento de um produto novo não existem muitas referências para tomar por base.

Espera-se então, do designer de interfaces interativas, que consiga oferecer com um produto as orientações básicas para a formação de um modelo mental do funcionamento e operação de um artefato. Há uma linha tênue, porém, que divide a construção de uma interface que oriente a interação e a formação de modelos mentais e a construção de uma interface nova, mas baseada em previsões sobre os modelos mentais que serão desenvolvidos pelos usuários.

Referências Bibliográficas

PREECE, Jennifer. Design de Interação: além da interação homem-computador / Jennifer Preece, Yvonne Rogers e Helen Sharp/ trad. Viviane Possamai. – Porto Alegre: Bookman, 2005

PARUCH, Avi. Interview with Donald Norman on Mental Models. Human Oriented Technologies Lab, 25 de fevereiro de 2004. Disponível em: <http://www.carleton.ca/hotlab/hottopics/Articles/April2004-InterviewwithDo.html>. Acesso em: 12 Jan. 2009

Conforme anunciado em novembro, hoje, primeiro de janeiro de 2009, o Spaghetti* Framework foi lançado oficialmente e liberado para download. No site você encontrará tudo o que precisa saber para começar a desenvolver, além de mais informações sobre o projeto.

O ano de 2009 será um ano de muito trabalho no Spaghetti*, mas também será um ano de cultivar o desenvolvimento Web produtivo.

Neste ano eu realmente aprendi PHP, eu realmente aprendi design de interação, e tanto aprendizado vai se refletir aqui no blog daqui em diante. Para 2009 grandes mudanças estão previstas por aqui, então espero sinceramente que vocês estejam aqui para conferí-las.

Que o ano que prospera seja um ano de sucesso para todos nós.

Grande abraço, e até 2009!

É, meus amigos, este é o motivo da minha ausência nos ultimos tempos. Um projeto interessante me tomou bastante tempo, e quero hoje, junto com o Julio Greff, anunciar que ele está quase pronto. Pessoal, com vocês, o nosso Spaghetti* Framework. Um framework para pequenas e médias aplicações.

Desenvolver para Web hoje já requer certa maturidade, quem não desenvolve um workflow produtivo dificilmente consegue se manter no mercado. Sentimos necessidade de uma ferramenta que tornasse nosso trabalho mais rápido, produtivo e divertido, porém sem perder qualidade. Usamos alguns frameworks e cogitamos outras possibilidades. Porém os frameworks PHP existentes até então eram grandes e inflexíveis demais para nossas necessidades reais, e migrar de linguagem é algo custoso, que requer uma curva de aprendizagem maior e um tempo que não tínhamos.

Chegou a hora de fazer nosso próprio framework.

A proposta inicial era pouco pretenciosa: um framework simples, sem MVC, mas que contivesse um modelo de dados e suporte nativo às URLs amigáveis. Essa era a nossa primeira versão e nosso primeiro escopo. Porém os projetos foram crescendo em número e dimensões, e sentimos que MVC seria a melhor solução. O Julio fez a escolha certa ao escolher o design pattern mais badalado do meio. MVC nos trouxe uma grande flexibilidade, que nunca haviamos conseguido antes.

Foram alguns meses de trabalho, tanto meu quanto do Julio, e acreditamos que o diferencial do nosso framework é que durante todo o processo de desenvolvimento do Spaghetti ele foi utilizado na prática. Sem cookbooks, sem 15-minute blog tutorials. Para cada etapa do processo de desenvolvimento do core do Spaghetti foi desenvolvido um Website ou sistema real, que hoje encontra-se em produção, funcionando.

Desde a versão não-MVC, há sites de clientes da agência onde trabalhamos rodando o Spaghetti. No meu ponto de vista isso é positivo, pois desenvolvemos uma plataforma baseada em problemas reais, com clientes reais e ambientes reais de desenvolvimento. Por isso, pensamos no Spaghetti como um framework sem utopias. O que existe é o que é usado de verdade.

Flexibilidade é a palavra de honra. CMSs geralmente limitam as capacidades dos desenvolvedores Web / clientes. Frameworks são super flexíveis em todos os aspectos, e não queremos ser diferentes nesse quesito. As funcionalidades já embutidas podem ser expandidas e novas podem ser adicionadas com Componentes que você mesmo pode escrever.

A que pé estamos?

O Spaghetti hoje supre muito bem todas as necessidades de desenvolvimento da nossa equipe na agência. Porém, estamos tornando esse projeto público. Ou seja, precisamos documentar tudo excepcionalmente bem, gravar screencasts, tutoriais, e até fazer um cookbook. Ou seja, nosso framework está pronto para uso, porém ele ainda não está pronto para que vocês, que estão conhecendo ele agora, saibam de tudo que ele é capaz.

Caso você seja curioso – e garanto que é – deve estar pensando onde está o código. Caso você queira dar uma olhada (por enquanto por sua conta e risco – já que não há documentação ainda), você pode acessar nosso Trac, e lá há inclusive o histórico de versões e revisões.

Lançamento oficial do release estável

[UPDATE] O lançamento oficial do Spaghetti* aconteceu em 1 de janeiro de 2009, junto ao lançamento do site oficial em www.spaghettiphp.org.

Fiquei supreso hoje quando abri o Feedburner. E não é que este blog chegou aos 200 assinantes do RSS? Eu já tinha ficado muito, mas muito contente quando cheguei a primeira centena. Mas agora vocês se superaram, hein fanfarrões! As pessoas mais próximas de mim já têm uma idéia das novidades que estão por vir. Mudanças bastante interessantes estão sendo planejadas neste exato momento e você, fiel leitor, vai gostar do que vai ver.