Category: Coordinating User Interfaces for Consistency (1989)

Ianne Howards Koritzinsky GE Medical Systems

É preciso mais do que desejo para criar uma interface consistente, é necessário ferramentas e metodologias que deem suporte ao design. Sempre importante lembrar que é necessário e crítico o apoio político.

Novos designs consistentes exigem um novo modo de desenvolvimento, é óbvio que não acontece sem esforço, é preciso de estratégia e plano para realizar.

Produtos médicos também tem uma interface de usuário, não é somente software de aplicações de computador. O método antigo da época (1988) usando Fortran Style, consistia em misturar os códigos de interface com o código-fonte da aplicação.

A nova metodologia poderia ser definida como:

• Previsível: usuários antecipam que o sistema vai fazer Dependente: o sistema preenche as expectativas do usuário
• Formação de hábito: o sistema encoraja o desenvolvimento de padrões de comportamentoTransferível: habilidades podem ser transferir dados de uma aplicação para outra cavalinha
• Natural: a interface consistente com um entendimento do usuário.

Esses tópicos podem ser aplicado em uma aplicação única ou em muitas aplicações, até mesmo em produtos da mesma família. Assim quatro aspectos são inicialmente discutidos: o conceito do design, a aparência da interface, os diálogose os mecanismos de interação (Foley 1982, Blake 1986).

Desenvolvere o estilo é o mais fácil, ter apoio da direção e mudar a cultura da empresa são as tarefas que mais exigem esforço. Organizações estão sobre diveras pressõe diferentes, muitas vezes para entregar um produto rápido, e assim muitas vezes atropelam a consistência.

Richard Wolf, lotus development Corporation

Consistência significa que ações similares dos usuários levam a resultados similares, e assim, permitem que usuários transferiram os conhecimentos e habilidades de uma área para outra (skills). A consistência no mundo real é uma tarefa multifacetada, exige compreensão de requisições conflitantes.

A resolução desses conflitos a maioria das vezes é um problema de processo, não de tecnologia, assim, para atingir consistência é preciso ter uma visão de processo: o fluxo de informação e decisões pela organização.

Aspectos da consistência: consistência é composta de elementos conflitantes.

• Self consistency: consistência em relação a si mesmo, é relacionada as ações e modelos dentro de uma aplicação.
• Consistência entre aplicações: ações similares dos usuários em diferentes aplicações deve levar a resultados semelhantes, por exemplo: clicar na opção Arquivo -> Salvar.
• Histórica: é necessário que a aplicação seja consistente com as suas versões anteriores e diferentes plataformas (nota do autor: Android e IOS por exemplo).

Todos esses elementos ocasionam conflitos, que podem ser resolvidos por um indivíduo com uma perspectiva mais ampla: um arquiteto de interface de usuário. Sua função é ser o coordenador das decisões interface.

Deve gerenciar os esforços para consistência no produto, administração, marketing, até mesmo a documentação sobre uma família de produtos. Pode até existir um comitê e membros de interface cuja função é educar um grupo sobre os trade-offs envolvendo decisões interface e receber feedback.

Michael Good

Nota do autor: XUI é um termo utilizado no livro para se referir a um conjunto de métodos e objetivos de padrão de interface, buscando no Google não é encontrado resultados rápidos pois o termo não se popularizou como “X Window System” e “DECWindows”.

O X se originou no Projeto Athena no Instituto de Tecnologia de Massachusetts (MIT) em 1984. O protocolo X está na versão 11 (daí “X11”) desde setembro de 1987. A Fundação X.Org lidera o projeto X

Wikipedia

Em 1988 a criação do DECWindows já considerava diferentes tamanhos de monitores e até mesmo tablets, utilização de mouses com “muitos” botões, assim poderia ser utilizado desde pequenas telas até monitores maiores (nota do autor: está é uma preocupação constante e muito importante nos dias atuais, pois a variação de tamanhos e resoluções é ainda maior).

Este projeto envolveu centenas de pessoas, desde engenheiros, marqueteiros, escritores, administradores, vendedores, suporte, todos foram envolvidos em diferentes linhas do produto ao redor do mundo.

Método inclui a seguinte lista:

Guia de estilo de interface do usuário: uma técnica comum para criar consistência no estilo de interface do usuário é criar um guia de estilo (Apple 1987). Guia de estilo descreve o elemento do estilo da interface do usuário e mostra exemplos do seu uso, também pode conter filosofia e princípios que descrevem conceitos. Oo guia XUI tinha próximo de 150 páginas e 50 ilustrações.

Caixa de ferramentas ou toolkit: Guias de estilo tendem a ser mais efetivos quando acompanhado por ferramentas de desenvolvimento, do que só ter a sua implementação seguindo recomendações.

Consultoria e design: Carrol Campbell, em 1988, propôs que artefatos computacionais carregam teorias implícitas de interação humano-computador que muitas vezes não podem ser deduzidas em teorias explícitas (nota do autor: caso clássico de conhecimento tácito x explícito).

Comunicação eletrônica: centenas de pessoas trabalhando nesse projeto deveriam estar sempre em contato via e-mail (nota do autor: algo muito incomum e 1988, inovador para a época) até mesmo conferências eletrônicas mais de mil vezes foram usadas.

Desenvolvendo uma nova interface de estilo: dificuldade inicial é que o guia tocava muito na descrição de forma muito analítica dos estilos, assim, os desenvolvedores tentavam fazer implementações que eram muito diferentes uma das outras. Perceberam que desenvolveram o novo guia de estilo é como desenvolver uma nova academia de artes, a “XUI School of Design”, alguns padrões arquitetônicos, como Barroco, Gótico, em música, pintura, são facilmente reconhecidos após o contato com alguns exemplos.

Uma das soluções foi compartilhar protótipos de forma antecipada, pois fotos estáticas e abstratas de produtos de interfaces não comunicam tão bem quanto protótipos que podem ser utilizados.

Feiras de negociação de interface do usuário: percebeu-se uma enorme quantidade de diferentes protótipos, que muitas vezes não conversavam entre si e apesar, de seguirem o guia, muitas vezes não era nem sequer usáveis. Então foi “roubada” uma ideia das artes novamente e criou-se uma feira ou uma galeria para a disposição destes protótipos, onde 45 times puderam exibir seus designs para mais de 600 pessoas, que compareceram, desde engenheiros, administradores, escritores de software.

Além de ter gerado um excelente documento, essa feira permitiu algo muito mais importante que foi a criação de relacionamento entre as pessoas e equipes, times da Nova Inglaterra, Califórnia e França se conheceram nesse evento.

Após essa feira a impessoalidade por trás de troca de mensagens eletrônicas foi menor e uma convergência de interfaces começou a surgir com o tempo. Após um ano, uma segunda-feira chamada DECWindows Enterprise Fair foi criada, dessa vez com 55 exibidores e mais de 5500 pessoas em dois dias de evento, focando muito mais em protótipos funcionais do que slides.
Afinal, o sucesso da iniciativa foi graças a testes constantes de usuários e recebimento de feedback, os quais designers conseguiram fazer trade-offs.

Nota do autor: o resultado desta iniciativa foi tão poderoso que a sua implementação está em voga desde 1987, sendo o padrão do sistema Unix desde então, estudar o processo do seu desenvolvimento é entender a chave do sucesso de um guia de estilo tão duradouro e importante.

Bruce tognazzin

O computador MacIntosh atingiu um alto nível de consistência no seu software pelos esforços e planejamento da Apple Computer Corporation. Mas, de certa forma, podemos dizer que muito desse crédito se deve a fontes externas, como os desenvolvedores que criaram as aplicações, a imprensa que foi vigilante nas suas expectativas de consistência e até os usuários finais, que demandam alto nível de consistência, nunca visto antes nos computadores.

Assim que a gente observa que muitos desses elementos estão mais relacionados a pessoas do que com hardware e software, boa parte dos esforços era para que novos programas não parecessem uma nova aventura para o usuário do Apple 2. Consistência se tornou uma chave para acessibilidade.

A história da Apple mostra que seus computadores são lançados depois dos guidelines interface, algumas vezes, até mesmo meses após, quando já existe até uma segunda edição do guia.

No geral podemos agrupas as recomendação em tópicos:

• Flexibilidade: é necessário certo nível de flexibilidade para que o desenvolvedor não abandone o toolkit de interface e tente que criar a sua própria.
• Promoção: a Apple tinha um conhecido grupo chamado evangelistas, quem incentivavam e convenciam os desenvolvedores a fazer produtos de acordo com os guias da Apple.
• Usuários: são primeiramente os mais beneficiados pela consistência, porém, em certo ponto acabam se tornando os maiores críticos quando percebe a sua falta. Um princípio simples é o sistema não usar mensagens de erro dizendo que o usuário está errado, mas que o sistema foi mal concebido.
• Pessoal de vendas: esses deveriam aprender em menos de 5 minutos a atualizar o software, do contrário o abandonariam.
• Imprensa: semearam notícias de que o MacIntosh seria um computador com uma interface humana consistente. O que acabou criando um comprometimento mútuo e cobranças.
• Mouse: fazer interfaces para computadores sem mouse o que implicava na obrigação dos desenvolvedores tem uma interface para seus programas que funcionar sem sem o mouse (nota do autor: pode parecer ridículo nos dias de hoje pensar que para reduzir custos computadores eram empacotados sem o mouse).
• Suporte: para o sucesso de uma guidelines de interface é necessário suua implementação seja mais fácil do que evitá-la. Também, deve-se considerar que kit básico pode ser customizado, então deve ser distribuído como módulos e não impedir o usuário programador de fazer alterações.
• Expansão: os guias interfaces da Apple nunca estão prontos, pois eles são constantemente revistos.
• Quality Assurance: existe um pessoal treinado para encontrar bugs e inconsistência nas interfaces dos programas, sempre levando seus feedbacks para os desenvolvedores.
• Teste de Usuário: por fim, nada substitui o teste humano de interfaces com membros do público alvo. É impossível prever com clareza o que os usuários finais esperam no programa, então é preciso equilíbrio.

A conclusão é que muito do sucesso do MacIntosh da Apple pode ser pela sua consistência do olhar e sentir (look and feel). A consistência foi uma ideia abraçada por toda equipe.

Título original: Coordenando Consistência na Interface do Usuário (UI), Código, Ajuda Online e Documentação Multilingual/Multitarget

Gary Pearlman

Existem muitos tipos de texto associados com software. O código do programa, os comentários no código, especificações técnicas, mensagens de erro, documentação, material de referência e provavelmente outros.

Assim, é necessário ter o usuário em mente para ser consistente na linguagem. Então, um programador não é indicado para escrever a documentação para o usuário final, devido a sua mentalidade. Considerando o conhecimento de um programador, também não é adequado que ele desenha interfaces ou faça redação de textos.

Tecnicamente mudança exige um custo enorme, até mesmo para mudar o tipo de variável de inteiro para flutuante, tem que mudar a declaração da variável no programa, fazer um comentário, alterar a interface, modificar o manual, e até o menu de ajuda. Por isso, não é de se surpreender que o maior custo de um software seja em manutenção e mudanças.

Desde os primórdios da computação existem métodos e linguagens de programação e frameworks voltados para a interface do usuário, aonde essas mudanças são refletidas automaticamente. Uma das técnicas consiste em separar os problemas e descrevê-los de forma simples, colocá-los no banco de dados, e a partir daí várias soluções de textos podem ser sintetizadas (nota do autor: estamos falando de uma solução inovadora para 1989, que, dentro do contexto, pode ser implementada atualmente).

Desde a década de 80, termos como design interativo e fast prototype são considerados eufemismo para a expressão “não temos certeza do que nós estamos fazendo e vamos tentar alguma coisa, coletar dados e a partir daí trabalhar”. Porém esse esforço quase nunca é conseguido de uma forma sintética, sendo que algoritmos, ferramentas e métodos acabam sendo ambíguos, exigem esforço para sua implementação e nem sempre vale o custo.

Tradução do título original: Análise de custo benefícios para utilização corporativas de padrões interface de usuário (UI): qual o preço a pagar para um ver e sentir consistente?

Daniel Rosenberg

Grandes empresas de computação se esforçam e planejam a padronização de interface (UI) de muitas linhas e produtos. Do ponto de vista financeiro é complexo, porque, a princípio, com um investimento inicial baixo, pode-se resultar retornos, e potenciais economias, de longo prazo.

Para montar o modelo mental do sistema (UI) é preciso padrões de construção, de uma linguagem comum para navegação e apresentação de dados. Palavras como: arquivo, novo, deletar, salvar, sair, fazem parte do dicionário da aplicação.

A navegação por janelas é diferente em sistemas Windows, Linux e Mac. Isso é a parte visual, do ver e sentir (do inglês look and feel). A parte de sentir está mais relacionado aonde está o ícone de fechar a janela, qual desenho desse ícone, ou como uma usuária faz para rolar a barra de navegação para baixo. (Nota do autor: a diferença é bem clara em sistemas Android e IOS, onde temos botões de ações, às vezes com os mesmos títulos, mas muito diferentes na tela).

Usuários experientes de computador estão tão acostumadas que nem param para pensar quantos comandos são necessários para arrastar um arquivo entre pastas. Depois que se aprende, fica intuitivo.

Uma interface consistência traz benefícios de marketing, usabilidade, valor do serviço, desenvolvimento e qualidade, e como estamos vendo, em finanças. É difícil avaliar, pois só sabemos o custo do desenvolvimento e antecipar o sucesso da qualidade e seu impacto nas vendas é difícil, imprevisível.

Estima-se que o desenvolvimento da interface do usuário (UI) pode representar um terço das linhas de código de um sistema (Smith, 1984). Uma conta simples para determinar o retorno seria utilizar (ou reutilizar) 20% do código para cada novo produto, assim, o 5º produto da mesma família, pagaria o esforço desenvolvimento de uma interface consistente.

Estratégias de marketing podem ser divididas em três:

1. A primeira seria não desenvolver interfaces, somente componentes.
2. A segunda é copiar a interface de uma outra empresa e,
3. A terceira criar uma interface única

Ao optar pela terceira, deve se levar em conta diferentes dispositivos e tamanhos de telas (responsividade).

Questões legais também deve ser consideradas (nota do autor: o livro foi escrito para o mercado dos Estados Unidos, assim a simples tradução não refleteria a realidade do ordenamento jurídico brasileiro). Nos Estados unidos é possível patentear o código e o ver e sentir (look and feel). Existem diversas jurisprudência sobre o tema, o que obriga empresas a expressarem de formas diferentes interfaces, porém a ideia básica por trás não pode ser patenteada. As patentes geralmente são compostas de diagramas e modelos de operação lógicos. (nota do autor: no Brasil não é possível patentar design de telas de software nem código-fonte de programas, são considerados produção autoral, como um livro, o que resulta em outras implicações legais)

Wendy A. Kellogg

Em algumas situações exceções podem ajudar na rotina de desenvolvimento, se pensar no processo de lavar roupa, o que você faz quando encontrar uma roupa manchada? Não podemos ter um processo único para todos os casos, para lavar roupa, para interface (UI) ou outros. Apesar da exceções serem um risco para a consistência são necessários para a usabilidade.

O esforço da coordenação da consistência é para controlar proliferação de designs. Usuários generalizam, de forma certa ou errada, com base nas suas experiências anteriores. Consistência não tem uma definição própria tem a ver com relacionamentos. Então como saber o que é consistente?

Para isso é preciso saber consistente em relação a quê. algo pode ser consistente em relação a uma coisa e inconsistente em relação a outra coisa. É muito difícil descrever as dimensões da consistência, geralmente focamos nos aspectos visuais e comportamentais.

Para alguns estudos foram criados interfaces com aparência parecida mas comportamento inconsistência para ações. Alguns ícones de ações podem ser mais facilmente entendidos pelos usuários quando representam ações do mundo real como tirar uma folha de papel de uma pasta (nota do autor: ou como meu vizinho de 96 anos me explicou como fazia para enviar um foto para seu filho no WhatsApp, tem que “apertar o clips”). Porém nomear um ícone com o desenho de uma pasta com o título “carro”, são coisas distintas, gera uma grande confusão no usuário.

Ações iguais como arrastar um arquivo pode ter resultados diferentes, arrastar um arquivo para outra pasta move o arquivo, mas a mesma ação de arrastar, se for levando o arquivo para um HD externo faz uma cópia do mesmo, preservando original, já arrastar para lixeira o remove do sistema. O comportamento consistente, para ser vantajoso, é preciso considerar o contexto.

É preciso saber como o componente será usado para entender a sua consistência. É preciso lembrar que a interface do usuário (UI) é um conceito abstrato e a sua aplicação pode trazer contradição de uma forma geral.

Uma forma é definir consistência por especificação, a definição da arquitetura da interface associada a regras para componentes padrões (desenhar como serão os botões, menus, scrolls), mas como consistência tem a ver com o contexto, regras rígidas podem não considerar cenários específicos.

Outras formas é a consistência por explicação e exemplo, suas regras não são tão detalhadas e permitem os desenvolvedores terem mais liberdades. A contrapartida da sua adoção é que não garante a consistência entre vários sistemas.