Criando a experiência da colisão de nome de arquivo do Windows 8

Criando o Windows 8

Nos bastidores com a equipe de engenharia do Windows

Criando a experiência da colisão de nome de arquivo do Windows 8

  • Comments 1

Agradeço imensamente todos os comentários sobre os nossos esforços para melhorar as funções básicas de gerenciamento de arquivos. Estamos muito contentes com esta troca de ideias. Há muita empolgação por causa das alterações que estamos realizando e muita energia em torno desse tópico. Isso é o que torna trabalhar no Windows 8 tão divertido. Recebemos muitos comentários e sugestões sobre muitas partes mencionadas, porém, de longe, o assunto mais comentado (expressando, com certeza, todos os lados da questão) veio da discussão sobre a caixa de diálogo de colisão de nome de arquivo (uma caixa de diálogo!). Pensamos que seria uma boa ideia desenterrar os arquivos de design lá do ciclo de desenvolvimento e mostrar a vocês o que levamos em conta e como chegamos até aqui. Mais adiante, com certeza voltaremos a esse assunto e falaremos sobre todas as alterações que possamos vir a realizar, mas pensamos que seria mais proveitoso agora dedicar nossa atenção à evolução de nosso design. Esta postagem foi criada por um grupo de pessoas que trabalhou nesse recurso (todos também trabalharam em outras partes do Windows 8): Ben Truelove (designer), Matt Duignan (pesquisador UX), Jon Class e Ilana Smith (gerentes de programa). --Steven

Nossa postagem anterior sobre a nova experiência de cópia no Windows 8 gerou muitas perguntas e comentários sobre a nova caixa de diálogo [Choose Files] (Escolher Arquivos) para resolver o problema de colisões de nomes de arquivos. Com base no nível de interesse, pensamos que seria divertido compartilhar algumas das iterações de design e o teste de uso que nos levou a esse design.

No design implementado, há dois níveis de controle ao atuar em colisões (ou “conflitos”) de nome de arquivo.

  • A experiência principal é um gerenciamento em massa de todos os conflitos, simplificado e com um único clique, que oferece as opções de [Replace all] (Substituir tudo) ou [Skip all] (Ignorar tudo). Chamamos isso de caixa de diálogo [Simple Conflict Resolution] (Resolução Simples de Conflitos).
  • Há também a opção de inserir uma experiência secundária, que oferece mais informações e um controle mais refinado. Esta é a caixa de diálogo [Detailed Conflict Resolution] (Resolução Detalhada de Conflitos).

Figura 1 - Caixas de diálogos finais

Windows 7 e anterior

A resolução das colisões de nome de arquivo é uma tarefa essencialmente complicada, pois envolve uma escolha significativa entre duas coisas muito semelhantes.

Veja como lidamos com essa questão lá no Windows 3.1:

Figura 2 - Conflito do Windows 3.1

Certamente fizemos algum progresso quando chegamos no Windows 7:

Figura 3 - Caixa de diálogo de 

resolução de conflitos do Windows 7

No Windows 7, há muitas informações que auxiliam na escolha, e mais opções sobre que ações tomar. No Windows 8, pensamos em melhorar isso ainda mais, para que seja mais fácil fazer as escolhas certas de maneira mais eficiente e para que você possa realizar as tarefas de transferência de arquivo com mais rapidez. Como mencionamos, os comentários e as ligações para o suporte que recebemos sobre a caixa de diálogo existente foram claros: algumas pessoas tiveram dificuldade em localizar as informações necessárias para fazer uma escolha consciente em uma caixa de diálogo bastante complexa. Mesmo com a quantidade de trabalho que fazemos, às vezes, leva um bom tempo para que venha à tona algo que não funcione da maneira mais adequada. Vale lembrar que milhões de pessoas usaram cópias pré-lançadas do Windows 7 e esse não foi um grande tópico de discussão em nossos fóruns (o assunto chegou a surgir, mas não foi um tópico largamente discutido).

Melhorando a experiência no Windows 7

Primeiramente, procuramos por formas de manter a experiência basicamente a mesma, mas também melhorá-la otimizando as principais informações que são necessárias para se tomar uma decisão.

Figura 4 - Conceitos 

iniciais para resolução de conflitos em um arquivo único

Esses designs introduziram alguns conceitos que realmente ficaram:

  • Descartar rótulos desnecessários, como [Date modified:] (Data de modificação:), e textos explicativos óbvios nos permitiu apresentar os detalhes importantes em um relance.
  • Adjetivos de metadados foram enfatizados. Em vez de solicitar aos usuários que comparassem valores, como o tamanho do arquivo, usamos palavras resumidas como “Maior” para passar a ideia certa para os usuários.
  • Padrões inteligentes foram pré-selecionados, reduzindo o trabalho dos usuários.

Rápido e fluido: melhor gerenciamento em massa de conflitos

No Windows 8, queremos que você seja capaz de realizar tarefas com mais rapidez e eficiência - "rápido e fluido" são palavras-chave de design no Windows 8 para todos os nossos designs (seja sensível ao toque, mouse/teclado ou ambos). A nova grande iteração de design buscou maneiras de dar sequência a experiência coesa de progresso da cópia, manter os conflitos enfileirados em uma única caixa de diálogo e permitir que você gerencie-os de uma maneira mais otimizada.

A ideia de otimizar as opções [Replace all] (Substituir tudo) ou [Skip all] (Ignorar tudo) foi introduzida. Na maioria das vezes, você sabe exatamente o que está copiando e por que há um conflito, podendo fazer uma escolha simples sobre que ação tomar.

Figura 5 - Adicionando gerenciamento em 

massa

Para os casos em que você precisa de mais informações ou controle refinado, decidimos exibir as informações em “camadas” de maiores detalhes.

Começamos com duas camadas:

Figura 6 - Primeiras duas camadas

Então, tentamos três camadas:

Figura 7 - Três camadas

E terminamos novamente com uma camada:

Figura 8 - Uma camada

O design oferece muitos atributos positivos. E fornece muitas informações. Ao clicar nos cabeçalhos é possível selecionar tudo em uma coluna, o que realmente auxilia no gerenciamento de conflitos. Contudo, essa era uma parte muito complexa da interface do usuário para ser apresentada como experiência inicial.

Em vez disso, combinamos o melhor dessas opções no seguinte:

Figura 9 - Uma caixa de diálogo de 

duas camadas

Resolução de conflitos simples e detalhada

Estava claro que esse design se encaminhava para uma combinação balanceada de simplicidade e potência que se ajustaria aos padrões do usuário.

Infelizmente, identificamos um grande desafio nesse design: Ao selecionar [Let me pick] (Permita-me escolher), o resultado é confuso e demasiado complexo porque tanto as opções simplificadas quanto as avançadas estão disponíveis. Isso nos levou a um design no qual a caixa de diálogo [Simple Conflict Resolution] (Resolução Simples de Conflitos) e a caixa de diálogo [Detailed Conflict Resolution] (Resolução Detalhada de Conflitos) eram experiências distintas.

Figura 10 - Estrutura básica

Com essa decisão, nossa estrutura básica foi definida.

Retoques

Quando nos preparamos para o teste com usuários, iteramos o design.

  • Esclarecemos a confusão causada por uma única miniatura.
  • Tornamos a origem e o destino (e suas colunas) mais visíveis.
  • Nossa equipe de Assistência ao Usuário (os especialistas na criação dos textos que usamos em produtos, assistência e na Web) nos ajudou a melhorar o texto.

Figura 11 - Pré-teste

É interessante observar as semelhanças entre a caixa de diálogo [Simple Conflict Resolution] (Resolução Simples de Conflitos) e alguns dos primeiros designs criados para lidar com conflitos de arquivo único. Também é interessante notar o quanto ambos são semelhantes ao design final da caixa de diálogo.

Primeiro ciclo da pesquisa de uso

Em nossos testes de uso, nossos pesquisadores localizaram uma grupo diversificado de pessoas, que não trabalham na Microsoft e representam uma gama de diferentes níveis de habilidades e experiências. Mostramos a eles o software e pedimos que completassem um conjunto de tarefas. Ao ouvir enquanto eles descrevem seus processos de pensamento, usando um dispositivo de acompanhamento dos movimentos dos olhos para detectar como eles enxergam a interface do usuário e para medir o sucesso da conclusão da tarefa, coletamos informações valiosas sobre o que funciona (ou não) em um design.

É muito importante entender que os testes de uso são uma ferramenta que usamos. Qualquer um que já tenha usado essa ferramenta sabe que você tem de ser um especialista tanto no domínio quanto na criação dos testes, já que um observador tendencioso e a construção do teste podem facilmente levá-lo a uma falsa sensação de segurança ou a esforços para otimizar uma solução essencialmente falha. Para nos ajudar nesse aspecto, nossos testes são desenvolvidos por pesquisadores objetivos que entendem os limites do que pode ser testado e que também verificam se as conclusões tiradas de um teste coincidem com o que deve ser avaliado. No final das contas, as escolhas de design exigem o uso de diferentes dados qualitativos e quantitativos, assim como dados baseados na experiência e na intuição.

Sabíamos que aprenderíamos muito em nosso primeiro ciclo de testes de uso e que faríamos muitas alterações, portanto, usamos o Método RITE como nosso protocolo. A maioria dos estudos de uso testa a mesma interface do usuário com todos os usuários, mas com o RITE fazemos alterações contínuas entre participantes, com base no que aprendemos. (Testávamos com slides do PowerPoint nessa etapa e, portanto, as alterações eram baratas.)

No fim, não foi preciso realizar muitas alterações na caixa de diálogo [Simple Conflict Resolution] (Resolução Simples de Conflitos), pois ela se saía bem nos testes. Contudo, testamos muitas coisas diferentes para a caixa de diálogo [Detailed Conflict Resolution] (Resolução Detalhada de Conflitos):

Figura 12 - Caixas de diálogo 

testadas para o primeiro estudo RITE

Nossos aprendizados mais importantes:

  • Caixas de seleção são necessárias. Por mais que preferíssemos um visual mais limpo e sem caixa de seleção, esse visual simplesmente não se saiu bem nos testes. Os usuários não sabiam o que fazer quando apresentados à interface do usuário. Caixas de seleção são muito mais eficazes ao fornecer as indicações adequadas para a seleção. Fizemos questão de manter uma grande área clicável, de maneira que os usuários possam clicar na caixa de seleção, na miniatura ou no texto para selecionar um arquivo.

Figura 13 - Área clicável

Área clicável para selecionar arquivo

  • Combinar os adjetivos (por exemplo, “mais recente”, “maior”) e os metadados era confuso. Os usuários os interpretavam como dois conceitos diferentes. Os adjetivos eram particularmente problemáticos. As pessoas pensavam que eles eram títulos ou que descreviam o local do arquivo (por exemplo, “mais antigo” era entendido como os arquivos no destino porque eles estavam presentes antes da cópia).
  • As colunas precisavam ser mais distintas. À primeira vista, pareciam mais com a exibição Lado a Lado no Explorer do que com uma tabela.

Mais retoques

Não havia uma solução simples para a questão dos adjetivos e das colunas, o que levou a mais investigações no design:

Figura 14 - Retoques baseados em testes 

internos

Nós realmente nos esforçamos para definir da melhor maneira a hierarquia e a importância da origem/destino versus linhas de conflito. Experimentamos linhas verticais, mas elas separava demais a origem e o destino. No fim, optamos pelas linhas horizontais, combinadas com o nome do arquivo como um cabeçalho para dar mais destaque à diferença entre os conflitos. As caixas de seleção ajudaram a distinguir a escolha entre origem e destino sem interferir nessa distinção.

Algumas de nossas primeiras ideias foram descartadas nessa etapa do processo:

  • Sem escolhas padrão. Com os conflitos listados em uma página com barra de rolagem, os padrões representavam um alto risco de perda de dados. Uma linha sem seleção fará com que a cópia daquele arquivo seja ignorada, de maneira que nada seja perdido.
  • Sem adjetivos. Gostamos de “Mais recente” e “Maior”, mas eles provocavam confusão e os usuários acabavam utilizando os dados concretos.
    Como alternativa, para ajudar os usuários a fazer escolhas, optamos por sugestões mais sutis: os valores de metadados ''mais recente'' e ''maior'' estão em negrito na interface do usuário. Essa solução se mostrou surpreendentemente eficaz, sem introduzir novos conceitos nem provocar confusão.

Mais pesquisas de uso

No ciclo de testes de uso seguinte, estávamos caminhando para o design final e testamos menos alternativas:

Figura 15 - Segundo teste de uso

A terceira opção era claramente a melhor. A exibição em duas colunas é o uso mais eficiente de espaço e deixa as caixas de seleção mais próximas da pergunta. A data e a hora precisam estar na mesma linha porque representam um único valor.

A caixa de diálogo [Detailed Conflict Resolution] (Resolução Detalhada de Conflitos) também oferece os seguintes recursos que ajudarão quando muitas informações forem necessárias para se tomar uma decisão:

  • Clicar duas vezes na miniatura abrirá o arquivo.
  • Um clique com o botão direito do mouse na miniatura abrirá o menu de contexto padrão.
  • O textos azuis referentes à Origem e ao Destino serão clicáveis e abrirão esses locais no Explorer.
  • Focalizar na miniatura ou link mostrará uma dica de ferramenta com o caminho do arquivo completo.

Continuando a iteração

Continuamos a realizar mais estudos e a fazer pequenas alterações desde a pesquisa inicial, mas o design básico se manteve praticamente inalterado. É muito animador ver como é fácil para os usuários concluírem as tarefas de uso. A resolução de colisões de nome de arquivo é algo complicado, mas os usuários lidam com isso de maneira eficiente e bem-sucedida.

Figura 16 - Design final

Confira o vídeo em nossas postagens anteriores em funções básicas de gerenciamento de arquivo para ver esse design em ação.

Nós adoramos receber comentários e gostaríamos de usá-los para criar o melhor design possível. Por essa razão, estamos lendo cuidadosamente todos os seus comentários e estamos ansiosos para colocá-los em prática.

- Ben Truelove, Matt Duignan, Jon Class e Ilana Smith

(Caso você não tenha visto, muitos membros da nossa equipe fizeram comentários na postagem anterior a respeito de algumas das questões levantadas: Alex, Matt, Jordi e Jon.)