Desenvolvendo Windows 7

Windows Desktop Search

Um dos pontos dos comentáriosque recebemos foi o sobre desabilitar serviços e instalar componentes opcionais -- já falamos sobre nossa meta nessa área em artigos anteriores.  Uma das principais (mas não a única) motivações para querer esse tipo de controle é a percepção com relação ao desempenho e ao consumo de recursos de vários componentes da plataforma. Um dos objetivos do Windows é fornecer uma plataforma confiável e consistente para os desenvolvedores – na qual eles possam contar com a disponilibidade de serviços do sistema – assim como um conjunto de recursos de sistema operacional que possam potencialmente beneficiar a todos os usuários. Ao mesmo tempo, devemos fazer isso de maneira a usar os recursos do sistema de forma eficiente o bastante para que os benefícios compensem o custo. Temos consciência de que uma parte dos usuários acredita que essa equação só possa ser resolvida manualmente – da mesma forma que algumas pessoas acreditam que carros com transmissão manual consigam um melhor desempenho. Neste artigo, iremos avaliar a funcionalidade do desktop search sob o ponto de vista do trabalho que estamos fazendo, tanto como um componente de plataforma amplamente disponível quanto para fornecer uma rica funcionalidade para o usuário final. Iremos também avaliar os sacrifícios de engenharia envolvidos e as técnicas que usamos para criar uma solução ótima para todos.  Chris McConnell, SDE principal da equipe Find and Organize, contribuiu para esse artigo.  --Steven

Você é uma daquelas pessoas que acreditam que a indexação de pesquisa é o que faz a luzinha da sua unidade de disco piscar como louca? Você acha que é por isso que você está sendo dizimado quando joga games de tiro em primeira pessoa com seus amigos? Se sim, este artigo é para você! A equipe Find and Organize é quem cria o serviço ‘Windows Search’, que chamamos simplestemente de ‘indexador’. Uma reclamação que ouvimos de alguns usuários avançados do Vista é que eles querem desativar o indexador pois acreditam que está usando muitos recursos do sistema, oferecendo pouco em troca. De acordo com nossos dados de telemetria, um máximo de cerca de 1,5% dos usuários do Vista desativam o serviço de indexação e acreditamos que essa percepção seja o motivo pelo qual eles escolhem fazer isso.

O objetivo deste artigo é esclarecer a função do indexador e realçar o trabalho que estamos fazendo para garantir que ele use os recursos do sistema eficientemente. Vamos começar falando sonre a função do serviço de indexação – para quê serve? Por que devemos deixá-lo ativo?

Por que Indexar?

Os computadores de hoje em dia estão cheios de tipos sofisticados de arquivos, tais como documentos, fotos, música, vídeo e por aí vai. A quantidade de arquivos que as pessoas aramzenam em seus computadores cresce rapidamente, tornando cada vez mais difícil para elas encontrar o que procuram, independentemente do quão bem organizados estão (ou não) os seus arquivos. Cada vez mais, esses arquivos contêm uma estrutura bem definida, com propriedades de metadados que descrevem o seu conteúdo. Um arquivo de música típico contém propriedades que descrevem o artista, o nome do disco, ano de lançamento, gênero musical, duração da música, entre outros, que podem ser muito úteis quando pesquisamos músicas.

Embora as tecnologias de indexação de pesquisa datem dos primórdios do Windows, foi com o Windows Vista que a Microsoft introduziu um sistema operacional de consumo que trouxe essa funcionalidade para o usuário comum de forma mais significativa. Antes do Vista, as pesquisas eram bem rudimentares – geralmente uma força bruta passando por todos os arquivos do computador e olhando apenas propriedades de arquivos simples, tais como nome de arquivo, data da última alteração e tamanho, ou um índice específico de um aplicativo com dados específos àquele aplicativo. Com o Windows, uma opção de pesquisa mais abrangente permitia que você também olhasse o conteúdo dos arquivos, mas esse recurso não era muito usado. Era uma funcionalidade bem básica que tratava todos os arquivos da mesma forma, sem utilizar as ricas propriedades de metadados disponíveis nos arquivos.

No Windows Vista, o serviço de indexação está ativado por padrão e inclui suporte mais abrangente em termos da quantidade de formatos de arquivo e das propriedades que são indexadas. O indexador monitora pastas espefícicas em seu computador e cataloga o seu conteúdo para facilitar a pesquisa rápida nesses arquivos. Quando o Windows indexa os seus arquivos de música, ele sabe como extrair as propriedades específicas de música que serão mais provavelmente usadas em suas pesquisas. Isso permite suporte para pequisas mais robustas e exibições mais ricas de seus arquivos, que não eram possíveis antes. Mas essa indexação tem um preço e é aí que o trabalho de engenharia começa a ficar interessante. Existe um custo (em termos de recursos do sistema) que deve ser pago para permitir essa funcionalidade, e há sacrifícios envolvidos em quando e como você paga esse custo. Isso não é característico apenas da indexação – todos os recursos apresentam esse custo-benefício. 

Sacrifícios

Várias soluções de pesquisa seguiam o modelo tradicional de “grep”, o que significa que cada pesquisa lê todos os arquivos que você deseja pesquisar. Nesse caso, você pagava com o tempo, enquanto esperava a pesquisa ser executada. Quanto mais arquivos você pesquisava, mais tempo tinha que esperar cada vez que fazia uma pesquisa. Se quisesse fazer a mesma pesquisa de novo, você “pagaria” de novo. E o valor que ganhava em retorno não era muito grande, já que a funcionalidade de pesquisa não era particularmente robusta. Com o Windows Vista , oi indexador tenta ler todos os seus arquivos antes de você iniciar a pesquisa para que quando pesquise, o processo seja mais rápido e responsivo. Isso requer que o indexador rastreia todos os seus arquivos somente uma vez inicialmente, não cada vez que você faz uma pesquisa. Se o arquivo for alterado, o indexador recebe uma notificação (um evento “push”) para que leia o arquivo novamente. Quando o indexador lê um arquivo, ele extrai as infromações pertinentes sobre o arquivo de modo a permitir pesquisas e visualiações mais robustas. O grande desafio é fazer isso de maneira rápida o bastante para que o indexador esteja sempre atualizado e pronto para realizar suas pesquisas, mas também de uma forma que não tenha um efeito negativo no desempenho do sistema. Isso sempre exige um equilíbrio que requer sacrifícios, e há várias coisas que o indexador faz para manter o status de um bom cidadão do Windows e ao mesmo tempo garantir que o índice esteja sempre atualizado.

Cidadão Modelo

Muito trabalho foi feito para fazer com que o indexador seja um cidadão modelo do Windows. Escrevemos whitepaper abrangente sobre a questão, mas vale a pena cobrir alguns dos pontos chave aqui. Para começar, o indexador só monitora certas pastas, o que limita a quantidade de processamento a apenas os aruqivos com maior probabilidade de você pesquisar. O indexador também “diminui o passo” quando você está usando o computador ativamente. Ele indexa os arquivos mais lentamente ou pára completamente, dependendo do nível de atividade no computador. Quando o indexador está lendo arquivos ele usa CPU e I/O de baixa prioridade e libera imediatamente o arquivo se outro aplicativo precisar de acesso a ele.

É essencial que todas essas questões sejam tratadas corretamente para o indexador, não só por ser importante para os recursos criados pela nossa equipe (por exemplo, o Windows Search), mas também para a plataforma do Windows como um todo. Existem vários aplicativos que exigem a capacidade de pesquisar conteúdo de arquivos no computador, Imagine se cada um deles criassem sua própria versão do indexador! Mesmo que todos fizessem um ótimo trabalho, haveria uma enorme quantidade de atividades desnecessárias e redundantes sendo executadas no computador. Toda vez que você salvasse um document, haveria um enorme fluxo de atividades à medida que todos os indexadores começassem a acessar a nova versão do arquivo. Para evitar isso, o indexador é criado de forma a fazer o trabalho para qualquer aplicativo que deseja usá-lo e fornece uma plataforma aberta e API com flexibilidade e extensibilidade para desenvolvedores. A API é criada para ser flexível o bastante para atender às necessidades de todo o ecossistema do Windows. Logo de cara, o indexador conhece cerca de 200 tipos de arquivos comuns, catalogando quase 400 propriedades diferentes por padrão. E há suporte para que aplicativos adicionem novos tipos de arquivos e propriedades a qualquer momento. Os aplicativos também podem adicionar suporte para indexação de tipos de dados que não sejam baseados em arquivo, como por exemplo email. Alguns dos aplicativos que estão usando o indexador atualmente são Microsoft Office Outlook and OneNote, Lotus Notes, Windows Live Photo Gallery, Internet Explorer 8 e Google Desktop Search. Como acontece com todos os sistemas extensíveis, os desenvolvedores costumam achar formas criativas para seus componentes utilizarem os serviços do sistema. Um exemplo é a maneira como os componentes do Tablet PC utilizam o conteúdo do índice para melhorar a precisão do manuscrito.

Sempre Melhorando

Estamos sempre trabalhando para melhorar o desempenho e a confiabilidade do indexador. A versão 3 foi lançada no Windows Vista. Algumas das grandes melhorias dessa versão foram:

• O indexador é executado como um serviço do sistema em vez de como um processo do usuário. Isso minimize o impacto em cenários de vários usuários, por exemplo, apenas um catálogo por sistema resulta na redução do tamanho do catálogo e evita que o mesmo conteúdo seja reindexado repedidamente. Outros benefícios são obtidos da natureza robusta de serviços.
• O indexador emprega I/O de baixa prioridade para minimizar o impacto da indexação no tempo de resposta do coputador. Antes do Windows Vista, todas as I/O erram tratadas ma mesma maneira.

Já lançamos o Windows Search versão 4 como uma melhoria tanto para o Windows XP quanto para o Windows Vista. Essa versão vai ainda mais longe em termos de melhorias de desempenho e estabilidade, tais como:

• Melhorias significativas para todas as pesquisas que envolvem classificação, filtro ou agrupamento. Alguns exemplos no Vista incluem:
1. Melhnorias na obtenção de todos os resultados durante a classigicação ou agrupamento. Uma pesquisa típica passa a ser até 38% mais rápida.
2. O tempo de uso de CPU foi reduzido em 80%
3. O uso de memória foi reduzido em 20%
• A sobrecarga nos servidores de Exchange foi reduzida em mais de 95% quando o Outlook está sendo executado em modo online. Com versões anteriores do Windows Search, uma grande quantidade de clientes do Outlook executados em modo online podia facilmente sobrecarregar o servidor do Exchange.
• Maior confiabilidade, incluindo:
1. Fizemos várias correções para resolver situações reportadas pelos usuários que antes faziam com que a indexação parasse de funcionar.
2. Melhoramos a capacidade do indexador de prevenir e recuperar corrupções do índice. Agora, quando uma corrupção é identificada no catálogo, ele é sempre recriado automaticamente – antes isso só acontecia em algumas circunstâncias.
3. Adicionamos novos recursos de log e eventos para ajudar a determinar e corrigir problemas de confiabilidade.

E fizemos ainda mais para melhorar o desempenho e a confiabilidade do indexador no Windows 7, que você poderá em breve ver no PDC. Caso ainda acredite que o indexador só te traz problemas, temos algumas coisas que gostaríamos que você tentasse:

• Baixe e instale o Windows Search 4 (no Vista ou no XP).
• Baixe e instale o Indexer Gadget da Galeria de Gadgets do Windows Live (apenas no Vista). Esse gadget foi criado por uma pessoa da nossa equipe e fornece uma maneira rápida de ver a quantidade de itens indexados. Ele também permite que você interrompa a indexação ou faça com que ela seja executada em velocidade total (sem diminuir o passo).
• Caso você seja uma daquelas pessoas que gostam de se enfiar embaixo do carro para brincar com o motor, você pode usar o gerenciador de tarefas e/ou o gerenciador de recursos do Windows para monitorar o seguintes processos: SearchIndexer, SearchFilterHost, SearchProtocolHost.

Se você percebe que o sistema está lento e acha que o indexador é o culpado, observe o gadget à medida que trabalha no computador. O número de itens indexados está mudando de maneira significativa quando você percebe o problema? Se você interrompe o indexador, o sistema se recupera? Estamos sempre tentando melhorar a sua experiência de pesaquisa, então se ainda estiver tendo problemas, gostaríamos de ser informador. Envie seus comentários para idx-help@microsoft.com.

Chris McConnell
Find and Organize

Controle de Conta de Usuário

Prometemos que este blog daria uma visão geral da Engenharia do Windows 7 e isto significa que iríamos incluir todos os assuntos possíveis - de desempenho até interface do usuário, assuntos técnicos ou não e, claro, assuntos fáceis e assuntos controversos. Este artigo é sobre Controle de Conta de Usuário. Nosso autor é Ben Fathi, vice-presidente do Core Operating System Division (COSD). UAC é um recurso presente em vários aspectos da arquitetura do Windows (segurança, contas, interface do usuário, design e outros); vários outros membros da equipe contribuíram neste artigo.

Continuamos a valorizar o debate que os artigos parecem proporcionar – apostamos que (claro que não literalmente) este artigo arrancará comentários até do mais reservado de nossos leitores. Lembrem-se de fazer comentários construtivos e pertinentes ao assunto deste artigo.

Informamos que o servidor do blogs.msdn.com utiliza mecanismos de restrição a comentários com o objetivo de reduzir o spam. Nós não temos controle sobre isso e mantemos todas as opções “não moderado” selecionadas. Não é possível publicar as regras de proteção contra spam, já que isto vai de encontro a seu propósito (e eu as desconheço). Entretanto, peço desculpas se o seu comentário não for publicado. --Steven

Controle de Conta de Usuário (UAC) é, discutivelmente, uma das características mais controversas do Windows Vista. Por que a Microsoft adicionou todos esses popups ao Windows? Isso realmente melhora a segurança? Será que todos simplesmente não clicam em “continue”? Será que alguém em Redmond recebeu os comentários de usuários e revisores? Será que alguém já viu um comercial de TV sobre esse recurso?

Durante nosso trabalho com o Windows 7 examinamos cuidadosamente o UAC – analisando os comentários de usuários, volumes de dados, o ecossistema do software e o próprio Windows. Para começar, vamos analisar por que o UAC foi criado e nossa abordagem no Vista.

Por que utilizar o UAC

Deixando os detalhes técnicos de lado, o objetivo real do UAC é informá-lo antes que qualquer alteração “no sistema” seja feita no seu computador, permitindo, portanto, que você permaneça no comando de seu sistema. Uma “alteração não desejada” pode ser mal-intencionada, tal como um vírus desabilitando um firewall ou um rootkit silenciosamente dominando a máquina. Entretanto, uma “alteração não desejada” também pode ser uma ação por pessoas que possuem privilégios limitados, tais como uma criança tentando burlar o Controle dos Pais no computador da família ou um funcionário instalando um software proibido num computador de trabalho. O Windows NT sempre ofereceu suporte a tipos de contas múltiplas de usuário, uma das quais é o “usuário padrão”, que não possui os privilégios de administrador necessários para realizar alterações como aquelas. As empresas podem fornecer à maioria de seus funcionários (e freqüentemente o fazem) uma conta de usuário padrão ao mesmo tempo em que dão a alguns profissionais de IT privilégios de administrador. Um usuário padrão não pode fazer alterações de sistema, mesmo que acidentalmente, através do acesso a um website mal-intencionado ou ao instalar o programa errado. O controle sobre as alterações que a maioria das pessoas pode fazer no computador reduz o número de ligações para a central de suporte e o Custo Total de Propriedade (TCO) geral para a empresa. Em casa, um dos pais pode criar uma conta de usuário padrão para os filhos e utilizar o Controle dos Pais para protegê-los.

Porém, quando não se trata dos casos das empresas ou do Controle dos Pais, a maioria das máquinas (75%) possui uma única conta com privilégios totais de administrador. Isto se deve em parte ao fato de que a primeira conta de usuário é revertida automaticamente para administrador, já que é necessário que haja um para a máquina, e em parte ao fato de que as pessoas querem e esperam ter o controle sobre seu computador. Já que a maioria dos usuários possui uma conta de Administrador, isto criou historicamente um ambiente no qual a maioria dos aplicativos, bem como alguns dos componentes do Windows, sempre consideravam que poderiam realizar alterações do tipo sistema no próprio sistema.  Softwares escritos dessa forma não seriam eficazes para usuários padrão, tais como os casos do usuário na empresa e do controle dos pais mencionados acima. Além disso, dar a todos os aplicativos acesso irrestrito ao computador deixaria uma porta aberta para alterações danosas ao sistema, fossem elas intencionais (por malware) ou não intencionais (por softwares mal escritos).

Figura 1. Porcentagem de máquinas (servidores excluídos) com uma ou mais contas de usuário de janeiro de 2008 a junho de 2008.

O Controle de Conta de Usuário foi implementado no Vista a fim de abordar duas questões importantes: uma de incompatibilidade de software entre diferentes tipos de usuário e a outra de falta de conhecimento do usuário com relação a alterações no sistema. Expandimos os tipos de conta ao adicionar o Admin Protegido (PA), o qual se tornou o tipo padrão para a primeira conta no sistema. Quando um usuário PA entra no sistema, recebe dois tokens de segurança: um idêntico ao token do Usuário Padrão, que é suficiente para os privilégios mais básicos, e um segundo com privilégios totais de Administrador. Usuários padrão recebem somente o token básico, mas podem utilizar um token de Administrador de outra conta caso necessário.

Quando o sistema detecta que o usuário quer realizar uma operação que requer privilégios administrativos, a tela muda para o modo de “área de trabalho segura” e o usuário recebe um aviso pedindo sua aprovação. O motivo pelo qual a tela segue para “área de trabalho segura” é para evitar ataques por softwares mal-intencionados que tentam fazer com que você clique sim quando surge um aviso UAC utilizando uma cópia da interface do UAC (imitando a UI). Eles não conseguem fazer isso quando a área de trabalho está em seu estado de “segurança”. Usuários Admin Protegido são portanto informados sobre quaisquer alterações no sistema e só precisam clicar em sim para aprovar a ação. Um usuário padrão vê uma caixa de diálogo semelhante, mas que permite que ele digite as credenciais de Administrador (via senha, cartão com PIN, impressão digital, etc.) de outra conta a fim de acionar os privilégios de Administrador necessários para completar a ação. No caso de um sistema doméstico utilizando o Controle dos Pais, o responsável digitaria seu nome de usuário e senha para instalar o software, permitindo, portanto, que o responsável tenha o controle sobre softwares adicionados ao sistema ou alterações feitas neste. No caso das empresas, o administrador de IT pode controlar os avisos de acordo com as políticas da empresa de forma que o usuário padrão receba somente uma mensagem informando que ele não pode alterar o estado do sistema.

O que aprendemos até agora

Estamos sempre tentando melhorar o Windows, especialmente nas áreas que mais afetam nossos clientes. Esta seção irá tratar dos dados sobre o ecossistema, Windows e usuários finais – reconhecendo que os dados isoladamente não refletem as histórias de irritação e frustração que muitos leitores deste artigo podem estar sentindo.

O UAC teve impacto significativo sobre o ecossistema do software, os usuários do Vista e o próprio Windows. Conforme mencionado em artigos anteriores, há maneiras pelas quais nossos clientes podem nos enviar dados de forma voluntária e anônima sobre como utilizam nossos recursos (Programa de Aperfeiçoamento da Experiência do Usuário, Painel de Feedback do Windows, pesquisas com usuários, testes de campo com usuários, artigos em blogs e testes de utilização internos). Os dados e comentários que coletamos nos ajudam a tomar decisões informadas e a estabelecer prioridades com relação ao desenvolvimento de nossos recursos. A partir desses dados, aprendemos muito sobre o impacto do UAC.

Impacto sobre o ecossistema do software

O UAC causou uma redução radical no número de aplicativos que requerem privilégios de administrador desnecessariamente, o que acreditamos que melhora a qualidade geral do software e reduz os riscos inerentes a ele numa máquina que exige acesso total de administrador ao sistema.

Nos primeiros meses após o Vista ter sido colocado à disposição para uso, as pessoas recebiam avisos de UAC em 50% de suas “sessões” - uma sessão é tudo o que acontece entre o logon e o logoff ou dentro de 24 horas. Além disso, havia 775.312 aplicativos únicos (nota: isto mostra o volume de aplicativos únicos que o Windows suporta!) produzindo avisos (notem que instaladores e o próprio aplicativo não são considerados como o mesmo programa). Isso parece ser muito e realmente é, já que grande parte do ecossistema do software exigiu privilégios de administrador para sua execução. Como o ecossistema atualizou seu software, bem menos aplicativos estão exigindo privilégios de administrador. Dados do Programa de Aperfeiçoamento da Experiência do Usuário de agosto de 2008 indicam que o número de aplicativos e tarefas que geram um aviso caiu de 775.312 para 168.149.

Figura 2. Número de aplicativos e tarefas únicos gerando avisos UAC.

Essa redução significa que mais programas funcionam melhor para os Usuários Padrão sem gerar avisos toda vez que são executados nem alterar acidentalmente uma configuração administrativa ou do sistema. Além disso, também esperamos que conforme as pessoas utilizem suas máquinas por mais tempo, elas instalem novos programas ou alterem as configurações do Windows com menos freqüência, o que irá resultar num número menor de avisos; por outro lado, é justamente quando uma máquina é nova que há atividade extraordinariamente alta com relação a necessidades administrativas. Dados do Programa de Aperfeiçoamento da Experiência do Usuário indicam que o número de sessões com um ou mais avisos UAC caiu de 50% para 33% das sessões com o Vista SP1.

Figura 3. Porcentagem de sessões com avisos ao longo do tempo.

Impacto sobre o Windows

Um resultado imediato do UAC foi o aumento da qualidade da engenharia do Windows. Agora há bem menos componentes do Windows com acesso total ao sistema. Além disso, todos os componentes que ainda necessitam de acesso total ao sistema precisam pedir a permissão do usuário para obtê-lo. Sabemos através de nossos dados que o próprio Windows é responsável por aproximadamente 40% de todos os avisos UAC. Isto chama ainda mais atenção quando se observam os avisos mais freqüentes: os componentes do Windows foram responsáveis por 17 dos 50 avisos mais freqüentes de UAC no Vista e 29 dos 50 avisos mais freqüentes no Vista SP1. Algumas melhorias realizadas no Vista SP1 reduziram os avisos do Windows por parte de componentes utilizados freqüentemente, como o mecanismo de cópia, mas fica claro que há mais coisas que podemos (e vamos) fazer. O ecossistema também trabalhou bastante para reduzir seus avisos. Portanto, o número de componentes do Windows na lista dos 50 mais aumentou. O Windows tem uma chance maior de fazer alterações mais profundas em sua arquitetura no Windows 7, portanto podem esperar menos avisos dos componentes do Windows. A redução dos avisos no ecossistema do software e no Windows é uma proposição na qual não há perdedores. Ela permitirá que as pessoas se sintam confiantes na sua escolha de um software melhor que não realiza alterações potencialmente desestabilizadoras ao sistema e permite que elas identifiquem de forma mais imediata avisos importantes, oferecendo, portanto, uma sensação mais segura de controle.

Uma área importante de comentários que recebemos se refere ao número de avisos recebidos durante um download do Internet Explorer. Este é um exemplo específico de uma situação mais comum, onde uma caixa de diálogo de segurança de um aplicativo se sobrepõe ao Controle de Conta de Usuário. O IE vem utilizando desde o Service Pack 2 do XP uma caixa de diálogo de segurança para avisar aos usuários antes de executar programas da internet. No Vista, isto muitas vezes resulta num aviso duplo – a caixa de diálogo de segurança do IE seguida imediatamente por uma caixa de diálogo do UAC. Essa é uma área que deve ser abordada adequadamente.

Figura 4. Número dos 50 maiores geradores de avisos da Microsoft ao longo do tempo.

Impacto sobre os Clientes

Um clique adicional para fazer coisas corriqueiras como abrir o gerenciador de dispositivos, instalar programas ou desabilitar o firewall é por vezes confuso e frustrante para nossos usuários. Listamos abaixo uma amostra dos comentários que recebemos do Painel de Feedback do Windows:

• “Não gosto de ser perguntado incessantemente se quero fazer o que acabei de mandar o computador fazer”.
• “Sinto como se o Vista me pedisse para aprovar cada pequena coisa que faço no meu PC e acho isso muito desagradável”.
• “O pedido constante de entrada para realizar qualquer alteração é irritante. Mas é bom o fato de que faz com que meus filhos me peçam a senha para coisas que estão tentando alterar”.
• “Por favor simplifiquem o Controle de Conta de Usuário.....altamente confuso e incômodo às vezes”.

Compreendemos que adicionar um clique extra pode ser irritante, especialmente para usuários que possuem um bom conhecimento do que está ocorrendo com seu sistema (ou para pessoas que só estão tentando trabalhar). Entretanto, o benefício em potencial para a maioria dos usuários é que o UAC força malwares ou softwares mal escritos a se expor e a pedir sua autorização antes que possam potencialmente danificar o sistema.

Isso torna o sistema mais seguro? Se cada usuário do Windows fosse um especialista que compreendesse a causa e efeito de todas as operações, o aviso UAC faria total sentido e nada mal-intencionado passaria despercebido. A realidade é que algumas pessoas não lêem os avisos e portanto não se beneficiam deles (e ficam somente irritadas). No Vista, alguns usuários avançados preferiram desabilitar o UAC – uma configuração que é reconhecidamente difícil de encontrar. Não recomendamos que você faça isso, mas entendemos a utilidade de poder desabilitar o UAC. Para o restante que tenta entender o que está acontecendo ao ler o aviso UAC, há um benefício de segurança definido em potencial se você gastar algum tempo para analisar cada aviso e decidir se é algo que você deseja que aconteça. Entretanto, não tornamos as coisas fáceis para você – as caixas de diálogo no Vista não são fáceis de decifrar e por vezes não são memoráveis. Num estudo em laboratório conduzido por nós, somente 13% dos participantes puderam fornecer detalhes específicos sobre por que estavam vendo uma caixa de diálogo no Vista. Alguns sequer se lembravam de ter visto uma caixa de diálogo quando perguntados a respeito. Além disso, vemos que os clientes administradores aprovam 89% dos avisos no Vista e 91% no SP1. Estamos obviamente preocupados com o fato de que os usuários estejam reagindo por uma questão de hábito devido ao grande número de avisos ao invés de se concentrar nos avisos importantes e tomar decisões seguras. Muitos diriam que isto é totalmente previsível.

Figura 5. Porcentagem de avisos ao longo do tempo por tipo de aviso.

Figura 6. Porcentagem de avisos UAC autorizados ao longo do tempo.

Olhando para o futuro...

Agora que temos os dados e os comentários, podemos olhar para o futuro e ver como o UAC vai evoluir – continuamos a acreditar que o propósito que temos para o UAC é algo bom. Portanto, faz parte de nosso trabalho encontrar uma solução que não abandone este propósito. O UAC foi criado com a intenção de fazer com que você controle seu sistema, reduzindo o custo de propriedade ao longo do tempo e melhorando o ecossistema do software. Percebemos que percorremos somente parte do caminho no Vista e algumas pessoas acham que conseguimos o contrário.

Com base no que aprendemos a partir de nossos dados e comentários, precisamos abordar várias questões importantes no Windows 7:

• Reduzir avisos desnecessários ou duplicados no Windows e no ecossistema de tal forma que avisos importantes possam ser mais facilmente identificados.
• Possibilitar que nossos clientes se sintam mais seguros de que estão controlando seus sistemas.
• Fazer com que os avisos informem as pessoas para que façam escolhas mais seguras.
• Oferecer um controle melhor e mais evidente sobre o mecanismo.

Os benefícios que o UAC proporcionou ao ecossistema e ao Windows são claros; precisamos continuar com este trabalho. Ao habilitar os usuários padrão de forma bem sucedida, o UAC atingiu seu objetivo de oferecer a administradores IT e aos pais maior controle para bloquear seus sistemas para certos usuários. Conforme demonstrado por nossos dados acima, vimos o número de aplicativos externos e componentes do Windows que exigem privilégios de Administrador desnecessariamente cair de forma significativa. Isso também gera o benefício direto da redução da quantidade total de avisos que os usuários vêem, uma reclamação comum que recebemos freqüentemente. Seguindo adiante analisaremos os cenários que consideramos mais importantes para nossos usuários para que possamos nos assegurar de que nenhum deles incluirá avisos que possam ser evitados. Além disso, analisaremos os “maiores geradores de aviso” e continuaremos a colaborar com terceiros fornecedores de software e equipes internas da Microsoft para reduzir ainda mais avisos desnecessários.

Mais importante do que isso: conforme desenvolvemos o UAC para o Windows 7 vamos abordar as questões levantadas pelos comentários dos usuários e de satisfação com relação aos próprios avisos. Ficou claro para nós que vocês estão frustrados. Vocês acham que os avisos são freqüentes demais, irritantes e confusos. Ainda queremos dar a vocês controle sobre quais alterações podem ser feitas em seu sistema, mas queremos oferecer a vocês uma experiência geral melhor. Acreditamos que isso pode ser feito buscando dois princípios fundamentais. 1) Ampliar o controle que vocês têm sobre as notificações do UAC. Vamos continuar a dar a vocês controle sobre as alterações feitas em seu sistema, mas no Windows 7 também iremos oferecer opções de forma que quando vocês utilizarem o sistema como administrador poderão determinar a variedade de notificações que vão receber. 2) Oferecer informações adicionais e mais relevantes na interface com o usuário. Vamos melhorar a caixa de diálogo da UI para que vocês possam entender melhor e fazer escolhas mais informadas. Já realizamos testes com novos conceitos de design baseados nesse princípio através de nosso teste de utilização interno e obtivemos resultados muito positivos. 83% dos participantes puderam fornecer detalhes específicos sobre por que estavam vendo uma caixa de diálogo. Os participantes preferiram os novos conceitos porque eles são “simples”, “destacam editores verificados”, “fornecem a origem do arquivo” e “fazem uma pergunta relevante".

Resumindo, sim, ouvimos as reações ao recurso do UAC – tanto positivas quanto negativas. Planejamos continuar a desenvolver os benefícios oferecidos pelo UAC como um agente para o usuário padrão, tornando os sistemas mais seguros. Ao fazê-lo, também abordaremos os inúmeros comentários de que a experiência do usuário deve melhorar.

Ben Fathi

Acompanhamento: Gerenciamento das janelas do Windows

Há muitas discussões interessantes vindas do artigo de organização de janelas. Isto realmente mostra o quanto esses detalhes representam para as pessoas. Ter a possibilidade de organizar como os aplicativos são mostrados na tela é muito importante para a produtividade por causa de seu impacto sobre quase todas as tarefas. Também é algo muito pessoal: as pessoas querem controlar seu ambiente de trabalho e organizá-lo da forma que mais lhe convém.

Uma coisa deve ficar clara: seria impossível para nós oferecer soluções para todas as maneiras diferentes que as pessoas gostariam de trabalhar e todas as ferramentas e possibilidades diferentes que já sugeriram - acho que todos podem perceber o quão sobrecarregados nós ficaríamos com opções e UI absorvendo todas as sugestões! Num primeiro momento isso pode parecer um pouco chato, mas algo de que gostamos muito foi ouvir sobre todas as ferramentas e utilitários que vocês utilizam (e escrevem!) para fazer de um PC Windows o seu PC. Nosso objetivo não é oferecer soluções para cada possibilidade imaginável de gerenciar sua área de trabalho, mas sim oferecer uma maneira incrível de gerenciar sua área de trabalho junto com customizações e personalizações, além de uma plataforma onde as pessoas possam desenvolver ferramentas que melhorem ainda mais a área de trabalho de formas únicas e inovadoras. Como já falamos antes, até mesmo isso é um desafio enorme, já que não podemos oferecer customizações e ganchos infinitos – isto realmente é tecnicamente impossível. Mas com essa abordagem o Windows oferece um alto grau (mas não infinito) de flexibilidade, desenvolvedores fornecem ferramentas adicionais, fabricantes de computadores podem diferenciar seus PCs e você pode ajustar a UI para tornar-se altamente personalizada e produtiva com relação ao modo que você quer trabalhar, utilizando uma combinação desses elementos com suas próprias preferências.

Outra coisa que vale a pena destacar é que muitos dos comentários aludiram a elementos do Windows discutidos muitas vezes, tais como desviar o foco das janelas, o registro ou gerenciar a ordem z das janelas - uma grande fonte de histórias e observações acertadas sobre APIs do Windows vem do blog de Raymond Chen. Raymond é desenvolvedor na equipe Windows há bastante tempo e é autor de Old New Thing, The: Practical Development Throughout the Evolution of Windows. Esta também é uma boa fonte de leitura sobre onde ficam as fronteiras entre o que o Windows faz e o que os desenvolvedores de aplicativos podem optar por assumir a responsabilidade e realizar (e o que são capazes de customizar).

Após essa introdução, Dave gostaria de continuar com algumas idéias que a equipe retirou das discussões. --Steven

Vimos várias idéias aparecendo de forma consistente através dos comentários. Parafraseando os comentários (mais detalhes abaixo), parece que há sentimentos fortes quanto a estes pontos:

• O tamanho das janelas é importante, mas perder tempo ajustando seu tamanho é irritante.
• Deixem que eu decida onde as janelas ficam - eu sei onde minhas janelas devem ficar.
• Arrastar arquivos pela tela é incômodo porque a janela-alvo por vezes fica escondida.
• Busquem maneiras melhores de dar uma olhada nas janelas em execução a fim de encontrar aquela para a qual desejamos mudar.
• Quero uma maneira previsível de fazer com que a janela se ajuste ao conteúdo (não necessariamente maximizada).
• Quero manter a minha cor personalizada de transparência, mesmo quando uma janela está maximizada.

Para cada uma dessas necessidades, há muita discussão interessante quanto a possíveis soluções – tanto recursos de outros produtos quanto abordagens totalmente novas. Fica claro depois desses comentários que há o desejo por melhoras e que vocês vêm refletindo sobre essa área há tempo suficiente para pensar em recomendações razoavelmente detalhadas! Abaixo estão trechos de algumas conversas em andamento nos comentários.

Ponham as janelas onde eu as quero

É muito interessante ver as pessoas discutindo sobre os recursos existentes e onde funcionam ou não funcionam.

Por exemplo, @d_e é fã das opções lado a lado existentes na barra de tarefas:

Na verdade, é muito fácil organizar as janelas no modo dividir janelas: Pressione CTRL enquanto seleciona múltiplas janelas na barra de tarefas. Depois clique no botão direito do mouse e selecione uma das opções lado a lado...

Mas essa abordagem não cumpre totalmente seu propósito para @Xepol:

Quanto às teclas de reordenamento de janelas na barra de tarefas -> sei que estavam lá desde o Win95, mas nunca as uso. Elas nunca fazem o que eu quero. Caso cheguem ao menos perto do layout certo, a ordem das janelas está errada. Já que eu tenho mesmo que arrastar coisas, é simplesmente mais fácil conseguir exatamente o que eu quero da primeira vez.

@Aengeln sugere levar a idéia básica de janelas lado a lado adiante a fim de torná-la realmente útil:

Um recurso realmente útil seria a possibilidade de dividir a área de trabalho em várias partes separadas, especialmente em telas maiores. Por exemplo, eu poderia querer maximizar minha janela do Messenger em uma parte menor no lado direito da área de trabalho e ainda assim poder maximizar outras janelas no espaço restante. Janelas não-maximizadas poderiam flutuar sobre ambas (todas) as partes da área de trabalho.

Parece que há um entendimento: otimizar o espaço da tela para mais de uma janela seria muito útil, se permitisse que você controlasse onde as janelas ficariam e se fosse fácil e rápido de usar todos os dias. Os recursos lado a lado atuais na barra de tarefas dão pistas de como isto poderia ser valioso, mas não são rápidos ou fáceis o suficiente para formar um hábito.

Abram no tamanho certo

Vimos muitos comentários sobre o “tamanho padrão” das janelas e perguntas sobre como isso é determinado. Os aplicativos escolhem qual tamanho terão ao abrir e geralmente utilizam o tamanho que tinham na última vez em que foram fechados (ou podem optar por não seguir essas configurações). Um dos casos que pode surpreender as pessoas é quando o IE abre uma janela pequena (websites às vezes fazem isso), pois uma vez fechada seu tamanho será o novo "último tamanho".

@magicalclick sugeriu uma solução:

Gostaria de ter mais um botão de legenda, de TAMANHO FIXO. Na verdade é uma caixa de seleção. Quando selecionamos a caixa, esta irá salvar o estado da janela para o aplicativo. Depois eu posso redimensionar/mover. Quando eu fechar a janela, ela não irá salvar as últimas alterações.

@steven_sinofsky ofereceu esta dica de usuário avançado que vocês podem utilizar para se tornar mais cliques-eficientes imediatamente:

@magicalclick Não gosto quando aquilo acontece! Ao invés de adicionar outra tecla ou espaço para clicar, eu faço o mesmo num clique com um truque de "usuário avançado" que é: quando você vir a janela pequena aberta, não a feche até que você abra antes outra cópia do aplicativo com o tamanho "normal" de janela. Então feche a janela pequena e depois a de tamanho normal.

Claro que isso é chato e quase impossível de se encontrar, mas é uma solução provavelmente melhor do que adicionar uma quarta possibilidade de UI na barra de título.

–steven

Encontrar a janela certa

A palavra utilizada é “Exposé”:

@Joey_j: O Windows precisa de um recurso parecido com Exposé. Quero ver todas as minhas janelas ao mesmo tempo.

@Dan.F: uma palavra - exposé. Copiem.

@GRiNSER : O Exposé possui suas próprias desvantagens: Assim como ter 30 janelas num macbook pro de tela 1400x1050 não é assim tão útil. Apesar de ser bem mais útil do que Horrível Flip 3D. O Exposé seria ainda mais útil com uma busca de janelas no teclado...

Independentemente do nome, existe uma vontade de encontrar visualmente a janela que você procura. Algo de acesso mais aleatório do que a abordagem por linha de tempo do Alt-Tab ou Flip-3d e algo que permita a você escolher a janela visualmente em um conjunto de miniaturas. Isto é muito útil quando se quer mudar de janela quando há várias delas abertas - mas algumas abordagens atuais não se ajustam bem e é possível que esse ajuste se torne um problema ainda mais difícil conforme as pessoas executem mais programas.

Arrastar arquivos

Houve vários comentários (e várias sugestões diferentes) sobre como facilitar o ato de arrastar entre janelas:

@Manicmarc:  Eu adoraria ver algo parecido com as pastas do Springloaded do Mac OS. Arraste algo sobre uma pasta e focalize, ela abre, arraste até a próxima pasta, solte.

@Juan Antonio: Seria útil poder abrir uma lista ou miniaturas das janelas ao arrastar um objeto a fim de selecionar em qual janela soltar o objeto.

Quanto a esse assunto, gostei muito do comentário de @Kosher sobre a diferença entre poder fazer algo e este algo parecer natural.

A UI poderia passar por muitas melhorias a fim de facilitar o ato de fazer as coisas. Não se trata somente do grau de facilidade, mas também do grau de suavidade com que o usuário transita entre fluxos de trabalho e tarefas UI comuns. Parece um pouco com como explicar a diferença entre uma Ferrari e uma Toyota para alguém que nunca dirigiu uma Ferrari, então não sei se isso vai acontecer algum dia.

Estamos verdadeiramente incorporando esse pensamento no desenvolvimento do Windows 7. Mal posso esperar para saber com qual carro o Windows 7 será comparado assim que estiver disponível para um test-drive.

- Dave

Interface do usuário: Gerenciamento das janelas do Windows

Inicializamos a máquina, exibimos objetos na tela, iniciamos programas; o próximo passo é analisar um assunto bastante complexo que de certa forma chega ao papel central da interface gráfica do usuário – o gerenciamento de janelas. Dave Matthews é gerente de programas da equipe da central de experiência do usuário. Ele irá apresentar alguns dos dados e idéias que estão sendo utilizadas na engenharia do Windows 7. --Steven

O homônimo da linha de produtos Windows é simplesmente "janela” – o conceito de UI que mantém informações e controles relacionados na tela de forma organizada. Vamos usar este artigo para compartilhar um pouco de nossa experiência, pensamento e "filosofia de pm" por trás do planejamento e atualização desse recurso de UI bastante conhecido.

A idéia básica de utilizar janelas para organizar a UI não é nova – vem (pelo que sei) desde os primeiros experimentos com interfaces gráficas de usuário em Stanford há mais de 40 anos. Ainda é utilizada depois de todo esse tempo porque é uma maneira útil de apresentar conteúdo e as pessoas gostam de controlar como seu espaço na tela é utilizado. O recurso de “janelas móveis” não é absolutamente necessário para um sistema operacional – a maioria dos telefones celulares e dispositivos do tipo media center só mostram uma página de UI de cada vez – mas é conveniente quando se está fazendo várias coisas ao mesmo tempo ou trabalhando com mais de um aplicativo de uma só vez. O Windows 2.0 foi o primeiro lançamento Windows que permitiu o uso de janelas móveis sobrepostas (o Windows 1.0 só permitia que fossem colocadas lado a lado, mas não sobrepostas. O debate “lado a lado versus sobrepostas” tinha defensores famosos de cada lado – de um estava Bill Gates e no outro Charles Simonyi). Além disso, o Windows também possui o conceito único de “interface de documentos múltiplos” ou MDI, o que permite que um quadro de janela organize múltiplas janelas dentro dele. De certa forma isso é um precursor das interfaces por guias prevalentes nos navegadores.

Um comentário adicional: um dos primeiros debates que acompanharam as conversas "lado a lado versus sobrepostas" no início do projeto do Windows era sobre ter uma barra de menus no alto da tela ou uma cópia da barra de menus para cada janela (ou documento ou aplicativo). Esse era um debate importante no começo, já que a resolução da tela era tão limitada (VGA, 640x480) que a redundância da barra de menus causava um problema de espaço. Nos monitores de grande escala de hoje, essa redundância tornou-se um bem, já que chegar aos elementos de UI com um mouse ou somente identificar visualmente os elementos exige muito menos movimento. Vai entender!

Do Windows 2.0 para o Vista.

Uma área na qual venho me concentrando é a parte de “gerenciamento de janelas” do sistema – especificamente as características envolvidas em mover e organizar as janelas na tela (elas são diferentes dos controles para alternar entre janelas como a barra de tarefas e alt-tab, mas estão intimamente relacionados). Em geral, as pessoas esperam que seja possível mover, redimensionar, maximizar, minimizar e fechar as janelas e esperam que estas sejam organizadas de forma livre e sobrepostas, com a janela em uso disposta na frente. Essas transformações e as ferramentas de apoio (botões de legenda, barras de redimensionamento, etc.) fazem parte das capacidades básicas que permitem que as pessoas arrumem e organizem seu espaço de trabalho de acordo com sua preferência.

A fim de melhorar uma área de recursos como essa, nós analisamos o sistema atual minuciosamente – o que temos e o que funciona? Isto significa analisar a maneira pela qual está sendo utilizada no mercado por ISVs e a maneira pela qual é utilizada e entendida pelos clientes.

Botões de legenda oferecem uma maneira simples de minimizar, maximizar e fechar. Janelas redimensionáveis podem ser ajustadas a partir de qualquer uma de suas 4 margens.

Dados sobre Utilização no Mundo Real

Conforme levantado no artigo anterior sobre Barra de Tarefas, as pessoas mantêm em média de 6 a 9 janelas abertas durante uma sessão. Entretanto, ao observar os dados de clientes descobrimos que a maioria do tempo é gasta com somente uma ou duas janelas realmente visíveis na tela a qualquer tempo. É comum trocar de uma janela para outra dentre as várias abertas, mas geralmente poucas permanecem visíveis ao mesmo tempo.

Dados do Painel de Feedback do Windows

Como parte de nosso planejamento, observamos como as pessoas gastam seu tempo e energia ao mover e dimensionar suas janelas. Isso nos permite compreender o que está funcionando bem no sistema atual e o que poderia ser melhorado.

Por exemplo, sabemos que maximizar é um recurso amplamente utilizado porque ele otimiza o espaço de trabalho para uma janela enquanto continua sendo fácil alternar para outras. Os usuários reagem a esse conceito e o compreendem. Já que na maior parte do tempo os usuários concentram-se somente nas janelas, isso acaba sendo utilizado freqüentemente.  Sabemos que para muitos aplicativos as pessoas exigem cada um dos pixels (por exemplo, em planilhas nas quais alguns poucos pixels ganham toda uma linha extra de coluna) e portanto os recursos acima de maximizar para "tela cheia" se tornam comuns, mesmo para a produtividade do dia-a-dia.

Um problema sobre o qual ouvimos (tão recente quanto os comentários no artigo sobre barra de tarefas!) relativo ao maximizar no Vista é que a cor de transparência personalizada não é muito visível, pois as janelas e a barra de tarefas ficam escuras quando uma janela é maximizada. (No Vista você pode customizar a cor de transparência da janela - e em 29% das sessões uma cor personalizada foi escolhida). O visual mais escuro foi utilizado para ajudar a tornar evidente que a janela está em seu estado especial maximizado. Isso é importante porque se você não notar que uma janela está maximizada e então tentar movê-la, nada vai acontecer – e isso pode ser frustrante ou confuso. Para o Windows 7 estamos buscando uma abordagem diferente a fim de que a cor customizada possa ser mostrada mesmo quando uma janela está maximizada.

É interessante notar que as pessoas nem sempre maximizam suas janelas mesmo quando só estão usando uma janela de cada vez. Acreditamos que um motivo importante é que muitas vezes é mais cômodo ler um documento de texto quando a janela não é larga demais. A idéia de maximizar é menos útil num monitor largo quando este faz com que as frases num email se estendam por 50cm ao longo da tela; 10 ou 12 centímetros parece ser uma forma mais prazerosa de ler um texto. Isso é importante porque monitores largos de desktops estão se tornando mais comuns e monitores de aspecto mais largo estão ganhando terreno até mesmo em laptops. Já que o Windows não possui um modo maximizar feito para se ler dessa forma, as pessoas acabam por redimensionar manualmente suas janelas para torná-las tão altas quanto possível, mas de largura limitada. Essa é uma das áreas nas quais uma tarefa comum, como ler um documento, envolve ajustes excessivos nos tamanhos das janelas, pois o sistema não foi otimizado para aquele cenário no hardware atual.

Dados sobre resolução sugerem que monitores de proporção mais larga se tornarão a regra.

Poder ver duas janelas lado a lado também é uma necessidade razoavelmente comum. Existe uma variedade de motivos pelos quais alguém pode precisar fazer isso: comparar documentos, fazer referências a um documento em outro, copiar de um documento ou pasta para outro, etc. É preciso um certo número de movimentos com o mouse para colocar duas janelas lado a lado – posicionar e ajustar as duas janelas até que elas tenham o tamanho aproximado de aproximadamente metade da tela. Vemos isso com freqüência com dois aplicativos, tais como comparar um documento num editor de textos com o mesmo documento em formato portable reader.

Usuários com vários monitores conseguem um aumento geral na eficiência das tarefas devido ao fato de que a configuração é otimizada para o caso de se utilizar mais de uma janela ao mesmo tempo. Por exemplo, é muito fácil maximizar uma janela em cada um dos monitores para utilizar o espaço das telas de forma eficiente. Num estudo da Microsoft Research sobre multitarefas, descobriu-se que os participantes que tinham vários monitores podiam alternar entre janelas mais vezes ao clicar diretamente numa janela ao invés de usar a barra de tarefas, sugerindo que a janela para a qual desejam mudar já estava visível. É interessante notar que o número total de trocas entre as janelas foi menor. Em termos de eficiência das tarefas, o melhor clique é aquele que evitamos.

Relatório da pesquisa MSR.

Máquinas com um monitor são mais comuns do que aquelas com vários deles, mas os recursos de gerenciamento de janelas não são otimizados para ver múltiplas janelas ao mesmo tempo em um monitor. A barra de tarefas possui opções de menu de contexto para cascata, empilhar ou lado a lado, mas não achamos que são bem compreendidas ou amplamente utilizadas, então a maioria das pessoas acaba redimensionando e movendo manualmente suas janelas sempre que querem ver duas janelas lado a lado.

Um cenário interessante com múltiplas janelas ocorre quando uma delas é na verdade a área de trabalho. A área de trabalho ainda é comumente utilizada como uma pasta de armazenamento para arquivos importantes ou recentes e acreditamos que as pessoas precisam arrastar e soltar com relativa freqüência entre a área de trabalho e uma janela do explorer, email ou documento. O recurso “Mostrar Área de Trabalho” oferece acesso rápido à área de trabalho, mas também esconde a janela que você está tentando utilizar. Isto significa que você terá ou que encontrar e retornar à janela original ou evitar o recurso Mostrar Área de Trabalho e minimizar tudo manualmente. É muito interessante observar cenários como esse nos quais as pessoas acabam por gastar muito tempo ou esforço gerenciando janelas a fim de completar uma tarefa simples. Este tipo de experiência aparece em nossa telemetria quando vemos seqüências complexas repetidas. É preciso ainda mais trabalho para ver se são erros comuns ou se as pessoas estão tentando realizar uma tarefa de múltiplos passos.

Evolução do design

A fim de encontrar designs bem sucedidos para o sistema de gerenciamento de janelas exploramos várias direções para ver qual mais ajudará as pessoas a serem produtivas. Dos extremos de multitarefas até o foco num único item, buscamos soluções que sejam adequadas e ainda assim otimizadas para a utilização mais comum. Analisamos as abordagens existentes, tais como áreas de trabalho virtuais, que podem ajudar quando da utilização de um grande número de janelas diferentes (especialmente quando estão agrupadas em grupos relacionados), ou docking palettes que ajudem a organizar o espaço de forma eficiente (conforme se vê em aplicativos avançados tais como o Visual Studio). Também analisamos soluções novas adaptadas aos cenários que estamos tentando viabilizar.

Também temos que pensar sobre a variedade de aplicativos que o sistema precisa suportar. Aplicativos SDI (interface de documento único) apóiam-se fortemente no sistema operacional para que este forneça recursos de gerenciamento de janelas, enquanto aplicativos MDI (interface de documentos múltiplos) fornecem alguns dos controles de gerenciamento de janelas por si sós (UI com guias é uma abordagem que está se tornando cada vez mais popular para aplicativos MDI). Alguns aplicativos fornecem seus próprios controles de dimensionamento e de legenda a fim de obter uma aparência ou comportamento únicos. Cada uma dessas abordagens é válida e os diferentes estilos dos aplicativos precisam ser considerados ao se fazer quaisquer alterações no sistema.

Para o Windows 7 nosso objetivo é reduzir o número de cliques e movimentos precisos necessários para realizar atividades comuns. Com base nos dados e comentários que obtivemos de nossos clientes, vários cenários foram sugeridos como considerações importantes para o design. Assim como com todos os designs que estamos discutindo, é importante apresentar os cenários de utilização comuns, tomar decisões claras quanto aos padrões de utilização mais amplamente empregados, abordar necessidades novas e “não enunciadas” e também certificar-se de que manteremos nossa filosofia de “controle”. Alguns dos cenários em ascensão incluem:

• Poder ver de forma eficiente duas janelas ao mesmo tempo, com uma quantidade mínima de ajuste.
• Simplicidade ao ver um documento em sua altura total e numa largura de leitura confortável.
• Ver uma janela fácil e rapidamente na área de trabalho.
• As ações mais comuns deveriam exigir o mínimo de esforço – maximizar ou restaurar janelas mais rapidamente exigindo precisão mínima do mouse.
• Atalhos no teclado para substituir movimentos do mouse sempre que possível para usuários avançados.
• “Opções de janela úteis, previsíveis e eficientes para uma variedade de exibições: de laptops pequenos até telas de 30” ou mais largas; com monitor único ou múltiplos.
• Dispositivos de entrada diferentes e fáceis de usar: mouse, teclado, trackpad, caneta ou telas sensíveis ao toque.
• Cor de transparência customizada das janelas visível mesmo quando maximizadas.
• Geral – clientes se sentem no comando e o sistema torna mais rápido e fácil o processo de realizar tarefas.

Este último ponto é importante, pois a sensação de reação e controle é um teste importante para determinar se o design corresponde à forma na qual as pessoas trabalham. Colocamos designs e modelos no laboratório de utilização para observar como as pessoas reagem e assim que as vemos sorrindo e realizando suas tarefas facilmente sabemos que estamos no caminho certo. O sucesso máximo num design como esse é quando parece tão natural que se torna automático. Isso acontece quando as pessoas sentem que dominaram uma ferramenta conhecida e que o computador está se comportando com deveria.

Isso é um pouco de nossa experiência sobre como refletimos sobre o gerenciamento de janelas e sobre design evolutivo numa parte bem básica da UI. Mal podemos esperar pelos comentários e reações, especialmente assim que as pessoas começarem a ter acesso às compilações do Windows 7.

- Dave

Acompanhamento: Lançar, Iniciar e Alternar

Muita discussão em torno da barra de tarefas e interface do usuário associada. Chaitanya acredita que seria uma boa idéia resumir alguns dos comentários e pensamentos. --Steven

Gostaríamos de continuar falando sobre alguns temas levantados em comentários e emails. Este artigo trata de algumas observações sobre comentários consistentes apresentados (apesar de não universais) e também fornece mais contexto de engenharia / design para alguns dos desafios lançados.

Primeiro é preciso reforçar alguns pontos que foram citados de forma consistente:

• Muitos de vocês concordam que a Área de Notificação precisa ser mais bem administrada e customizada.
• Recebemos vários comentários sobre reorganizar os botões da barra de tarefas. Isto está relacionado à necessidade de um lugar previsível onde os botões da barra de tarefas apareçam bem como o pedido de vocês por mais controle sobre a barra de tarefas.
• Houve comentários que discutiram a utilidade da Inicialização Rápida, mas que ela poderia se tornar uma superfície ainda melhor de inicialização (por exemplo, um tamanho maior padrão ou mais espaço).
• Miniaturas são valiosas para muitos de vocês, mas o tamanho delas nem sempre ajuda a encontrar a janela que procuram. Há interesse num método melhor de identificação de janelas que forneça de forma consistente a quantidade correta de informação.
• Também se discutiu um melhor dimensionamento de janelas suportadas. Isso inclui otimizar a barra de tarefas para mais janelas e englobar exibições múltiplas.

Dados

Muitos de vocês perguntaram sobre as conclusões que estamos tirando dos dados que coletamos e como iremos proceder.

@Computermensch escreveu: “O problema dessa ‘análise’ (mostrem os dados) é que vocês só estão lidando com atividades em vigor relacionadas à barra de tarefas. Então, com relação à 'evolução da barra de tarefas', vocês só a estão desenvolvendo dentro da estrutura operacional atual enquanto o desenvolvimento ou evolução deveriam estar voltados para o desenvolvimento do conceito de barra de tarefas".

@Bluvg postou: “E se a própria UI fosse o motivo pelo qual as pessoas não executassem mais do que 6 a 9 janelas? Em outras palavras, e se a UI possui um número supremo de janelas em termos de efetividade? Priorizar o cenário em torno de 6 a 9 seria tirar uma conclusão errada a partir dos dados, se fosse o caso. A própria UI estaria ditando os dados, ao invés de estar sendo guiada pela demanda dos usuários".

Como já dissemos em todos os nossos artigos sobre dados que coletamos e como os utilizamos, os dados não se traduzem diretamente em nossos recursos, mas informam nossas decisões. A informação que coletamos a partir de instrumentação bem como de entrevistas com clientes oferece meramente mais exatidão sobre como um produto é usado atualmente no mundo real. O objetivo não é necessariamente só fazer design pelo status. Entretanto, temos que reconhecer que se um novo design que surge não alcança os objetivos e comportamento de nossos clientes hoje, corremos o risco da resistência. Isso não quer dizer que nunca se deve inovar e mudar o jogo – só que ao fazer isso devemos respeitar o objetivo maior do cliente. Oferecer uma nova solução para um problema é ótimo; só se certifique de que você está solucionando o problema certo e que existe um caminho entre onde as pessoas estão hoje e onde você acha que está a melhor solução. Tendo dito isso, podem ficar seguros de que nosso processo de design reconhece a necessidade de ajustar a barra de tarefas de modo mais eficiente para grupos maiores de janelas. Isso permitiria a aqueles que possivelmente se sentem “presos” no caso das 6 a 9 janelas se aventurar confortavelmente a abrir janelas adicionais, se realmente precisarem.  Além disso, as melhorias que fazemos para a maioria de 90% também deveriam beneficiar o restante.

Área de Notificação

Com tantos comentários, é sempre válido reconhecer quando eles têm algo em comum. O artigo original expôs os problemas com a Área de Notificação e essas questões foram ainda mais enfatizadas com os pensamentos de vocês.

@Jalf escreveu: “Ter 20 ícones e um balão de notificação a cada 30 segundos ocupando espaço na barra de tarefas onde *sempre* está ocupando espaço simplesmente não é legal. Concordo que a informação deve estar lá se eu precisar dela, mas simplesmente não podemos supor que se eu não buscar a informação ativamente é porque eu não a quero.

O comentário de Jalf é particularmente interessante porque aponta tanto os prós quanto os contras das notificações. Elas certamente podem ser valiosas, mas também podem facilmente sobrecarregar o cliente, como muitos de vocês notam. Devemos alcançar um equilíbrio cuidadoso tal que o cliente mantenha-se informado sobre coisas que são relevantes enquanto permanece no comando. Já que o que é relevante é relativo, a necessidade de controlar é fundamental. Fiquem certos de que estamos cientes dessas questões e as levamos muito a sério.

Suporte para múltiplos monitores

Não é surpresa que muitos de vocês escreveram para discutir suporte a múltiplos monitores para a barra de tarefas. Esse é um pedido freqüente de nossos entusiastas (e de nossos próprios desenvolvedores) e foi destacado como uma área de investigação no artigo original.

@Justausr é bem direto com seu comentário: “A falta de suporte a múltiplos monitores é praticamente um crime. Vimos fotos do escritório de Bill Gates e como ele usa 3 monitores. A maioria dos desenvolvedores tem 2 monitores hoje em dia. Por que não há suporte para múltiplos monitores na barra de tarefas? Mais uma vez esse é um exemplo da compartimentalização da equipe Windows e a falta de um direcionamento para o usuário quando da definição e implementação de recursos. O fato de que isso é somente uma "possibilidade" e não um "claro que nós vamos..." mostra que vocês AINDA não entendem".

Ao menos neste caso em particular tendemos a pensar que nós "entendemos", mas também tendemos a pensar que o desenvolvimento de uma barra de tarefas multi-monitores não é tão simples quanto parece. Assim como em muitos recursos, há mais de uma maneira de implementá-lo. Por exemplo, alguns poderiam sugerir uma barra de tarefas única para cada tela e outros sugerem uma barra de tarefas que se estenda por várias telas. Vamos analisar essas duas abordagens. Enquanto isso se lembrem das complexidades de se ter monitores de tamanhos, orientações e alinhamentos diferentes.

Se fôssemos implementar uma barra de tarefas para cada tela onde cada barra contivesse somente janelas para sua respectiva parte da área de trabalho, algumas questões surgiriam. Alguns clientes vão citar as vantagens de se andar menos com o mouse, já que sempre há uma barra na parte inferior da tela. Entretanto, tal design daria ao cliente o ônus de acompanhar onde as janelas estão. Imagine procurar uma janela do navegador e ao invés de ir para um único lugar ter agora que procurar em múltiplas barras de tarefa a fim de encontrar o item que você quer. Pior do que isso, quando você move uma janela de uma tela para a outra, teria que saber procurar num novo local para encontrá-la. Pode parecer que isso vai de encontro com o pedido para reorganizar os botões da barra de tarefas, pois os clientes querem que seus botões sejam automáticos. Seria como ter dois controles remotos com funcionalidades dinamicamente diferentes para sua TV. Essa é uma das razões pelas quais todas as implementações virtuais em áreas de trabalho mantêm uma barra de tarefas consistente apesar da área de trabalho na qual você está trabalhando.

Outra abordagem da qual muitos gostam é uma barra de tarefas que se estende por múltiplas áreas de trabalho. Há algumas ferramentas de terceiros que tentam emular essa funcionalidade para a barra de tarefas do Windows. A vantagem mais óbvia dessa abordagem (bem como da barra de tarefas dupla) é que sobra mais espaço para iniciar, alternar e murmurar. É razoavelmente óbvio que esses clientes com múltiplas telas têm mais espaço para ter mais janelas abertas simultaneamente e, portanto, requerem ainda mais espaço em sua barra de tarefas. Alguns dos nossos clientes avançados abordam essa questão aumentando a altura da barra de tarefas para exibir múltiplas linhas. Outros pedem uma barra de tarefas abrangente. Precisamos reconhecer que o problema não é necessariamente que a barra de tarefas não é abrangente, mas que é preciso mais espaço para mostrar mais informações sobre janelas. Então é lógico que devemos pensar na melhor solução para esse problema, independentemente de quantas telas o cliente possui.

Pensamos que seria bom ao menos oferecer uma breve discussão sobre os detalhes específicos sobre como resolver esse problema de design, já que é algo com que já gastamos bastante tempo. Uma das abordagens em geral na qual estamos trabalhando mais é mudar as coisas quando sabemos que trará uma melhoria substancial e não só introduzir complexidades que superem os benefícios que estamos tentando atingir.

Mais uma vez muito obrigada pelos seus comentários. Esperamos falar com vocês em breve.

- Chaitanya

Interface do usuário: Lançar, Iniciar e Alternar

Por onde começar? Neste artigo, Chaitanya Sareen, gerente sênior de programas da equipe da Central de Experiência do Usuário, estabelece um contexto de engenharia para o elemento de interface do usuário mais utilizado no Windows – a Barra de Tarefas do Windows. -- Steven

Não é surpresa que recebemos muitos comentários sobre a barra de tarefas e sua funcionalidade em geral. Também não deve ser surpresa que estamos constantemente tentando elevar os padrões e melhorar a experiência da barra de tarefas para nossos clientes enquanto nos asseguramos de que levamos adiante a conveniência e benefícios (e compatibilidade) da implementação e design atuais. Neste artigo gostaríamos de oferecer algumas idéias sobre essa barra modesta que fica possivelmente na parte inferior da sua área de trabalho Windows. Vamos analisar mais de perto suas várias partes, dados que coletamos e como esse aprendizado vai fornecer informações para a engenharia do Windows 7.

Barra de Tarefas - o Básico

Nossa barra de tarefas estreou no Windows 95 e a essência de sua funcionalidade permanece a mesma até hoje. Em resumo, ela possibilita funcionalidades para iniciar, alternar e "murmurar". A Figura 1 mostra a barra de tarefas do Vista e expõe sua anatomia básica. Algumas partes notáveis são a taskband, Inicialização Rápida, o Menu Iniciar, Barras de Ferramentas da Área de Trabalho (também conhecidas como Faixas de Trabalho) e a Área de Notificação. Coletivamente, esses componentes proporcionam alguns dos controles mais fundamentais para que os clientes iniciem, gerenciem e monitorem suas tarefas.

Fig. 1: Anatomia da Barra de Tarefas do Windows

Taskband: Alterna janelas de forma exata

A taskband é uma das partes mais importantes da barra de tarefas. Ela recebe botões que representam a maioria das janelas abertas na área de trabalho. Pense na taskband como um controle remoto para o seu computador – você pode alternar entre janelas exatamente como muda de canais na TV. A idéia de alternar entre janelas é o aspecto mais fundamental da barra de tarefas do Windows. Outros sistemas operacionais também têm barras na parte inferior da tela, apesar de que as deles possuem objetivos diferentes. Por exemplo, o Mac OS X têm um Dock que primariamente inicia programas e alterna entre programas. Clicar num ícone no Dock geralmente traz todas as janelas de um programa em execução. Em 2003 a Apple introduziu um alternador entre janelas conhecido como Exposé, o qual oferece uma abordagem visual diferente de nossa duradoura interface Alt-tab (o Flip 3D do Vista é mais uma abordagem visual). Todos esses alternadores especiais entre janelas têm o objetivo de fornecer aos clientes uma visão ampla de suas janelas abertas, mas cada um deles requer que o cliente o acione primeiro. Por outro lado, a taskband é feita para sempre permanecer visível a fim de que as janelas ofereçam sempre acesso rápido ao mouse. Isso faz com que a barra de tarefas seja o alternador de janelas que mais aparece no sistema operacional Windows.

Duas alterações na barra de tarefas dignas de nota foram introduzidas nos últimos oito anos. O Windows XP introduziu o agrupamento, o qual permite que os botões da barra de tarefas se juntem num único botão para economizar espaço e organizar as janelas de acordo com seu processo. O Vista apresentou as miniaturas da barra de tarefas. Essas representações visuais dão aos clientes mais informações sobre a janela que estão procurando. Apesar de válidas, interfaces como a barra de tarefas, Alt-tab e até o próprio Exposé da Apple revelam que as miniaturas nem sempre são suficientemente grandes para garantir o reconhecimento de uma janela. O valor delas torna-se ainda menor quando elas têm de diminuir para acomodar várias janelas abertas, um comentário que recebemos de pessoas que freqüentemente têm vários programas em execução versus muitas janelas abertas.

O Menu Iniciar: o ponto de partida do Windows

O Menu Iniciar sempre partiu da barra de tarefas como um ponto de partida para as principais tarefas do cliente, tais como iniciar ou acessar as funcionalidades do sistema. É claro que a Microsoft utilizou o termo “Iniciar” e nomeou claramente o botão do Menu Iniciar como tal. Você pode até se lembrar da enorme campanha de marketing para o Windows 95, a qual utilizou a música “Start Me Up” dos Rolling Stones. Falando sério, nossas pesquisas mostraram que muitos clientes nem sempre sabiam aonde ir em seus computadores para iniciar uma tarefa. Quando um cliente era colocado em frente a uma máquina com Windows 95, ele tinha um local claramente sinalizado para começar. E sim, nós já ouvimos a piada que diz que temos que clicar em iniciar para desligar a máquina. Por falar em desligar, encontramos alguns desafios com relação às opções de energia no Menu Iniciar do Vista. O objetivo era criar entusiasmo e divulgar a opção de suspensão para que os clientes se beneficiassem de um retorno mais rápido. Entretanto, agora sabemos que apesar de nossas boas intenções os clientes estão abrindo o sub-menu e selecionando outras opções. Estamos estudando como melhorar essa experiência.

O Menu Iniciar sofreu muitas mudanças ao longo dos anos. Uma mudança notável foi na aparência de uma seção MFU (mais freqüentemente utilizada) no Windows XP que sugere programas geralmente (ou freqüentemente) utilizados. O objetivo era economizar o tempo do cliente ao não obrigá-lo a ir sempre para Todos os Programas. Já que esses itens apareciam automaticamente com base na utilização, não era necessária nenhuma customização manual. O próprio Todos os Programas sofreu várias iterações. Os comentários dos clientes revelaram que as pessoas tinham dificuldade em percorrer o sub-menu Todos os Programas original. Não raro o mouse "escapava" do menu e então era preciso recomeçar a tarefa. Isso era especialmente o caso para clientes utilizando trackpads num laptop. Também não ajudava muito ver que ao expandir o menu este de repente ocupava toda a área de trabalho, o que dava uma impressão visual turbulenta e exigia muitos movimentos no mouse. E, claro, para máquinas com um grande número de itens e/ou grupos isso era especialmente complexo, ainda mais em telas pequenas. O Vista introduziu um menu único que requer menos acrobacias com o mouse.

A Busca foi outra soma importante ao Menu Iniciar que torna o ato de iniciar ainda mais fácil. Esse novo recurso no Vista oferece acesso rápido a programas e arquivos sem a necessidade de utilizar um mouse. Ao digitar uma frase aparecem rapidamente programas, arquivos e emails. Recebemos muitos comentários positivos de entusiastas que acham que esse é um ganho em desempenho importante em termos de “tempo para iniciar”. Talvez seja interessante notar que a busca do Menu Iniciar é otimizada para retornar primeiro resultados de programas, já que esse é visto como o cenário mais comum dentre nossos clientes (utilizando um pouco da tecnologia da Busca da Área de Trabalho). A Busca permite até que clientes utilizem parâmetros para expandir ainda mais suas consultas. Por exemplo, pode-se usar “para:john” ou “de:jane" para encontrar um email específico diretamente a partir do Menu Iniciar. Nossos clientes avançados também aproveitam o benefício de utilizar a busca do Menu Iniciar como um substituto para a Caixa de Diálogo Executar. Assim como digitariam o nome de um executável junto com algumas opções na caixa de diálogo, eles podem agora somente digitar diretamente no campo de busca. Nós poderíamos (e vamos) dedicar um artigo inteiro no blog somente a busca/pesquisa, mas esperamos que vocês tenham uma idéia de como uma busca certamente oferece uma alternativa poderosa de inicialização à navegação com o mouse.

Inicialização Rápida: Inicialização fácil

A Inicialização Rápida oferece aos clientes uma maneira de iniciar programas, arquivos, pastas e websites usados freqüentemente diretamente a partir da barra de tarefas. Ela foi introduzida no Windows 95 pelo Internet Explorer 4.0 com a Atualização da Área de Trabalho do Windows. Customizar a Inicialização Rápida é tão simples quanto arrastar atalhos até esta área. Economiza uma viagem até o Menu Iniciar, a área de trabalho ou a uma pasta quando você quer iniciar algo. Um recurso interessante da Inicialização Rápida que talvez vocês não conheçam é que ela sempre ofereceu suporte a ícones grandes (desbloqueie a barra de tarefas, clique com o botão direito do mouse em Inicialização Rápida e clique em ícones grandes em “Exibir”), conforme mostrado na figura 2. É claro que aumentar os ícones começa a interferir no espaço da taskband, um dos motivos pelos quais não habilitamos essa configuração de forma padrão. Separadamente, o Windows XP desligou a Inicialização Rápida de forma padrão numa tentativa de reduzir o número de superfícies de inicialização diferentes no Windows. Com base nos comentários de vocês, nós rapidamente retificamos esse passo em falso e a Inicialização Rápida foi ativada de forma padrão novamente. Não mexa com acesso rápido às coisas que as pessoas usam todos os dias! Ouvimos vocês claramente.

Fig. 2: Ícones Grandes na Inicialização Rápida. Há suporte para ícones grandes na barra de tarefas desde o Windows 95 com IE4.

Barras de Ferramentas da Área de Trabalho: Gadgets para a sua barra de tarefas

As Barras de Ferramentas da Área de Trabalho oferecem funcionalidades extensíveis e especializadas no nível superior da barra de tarefas. Essa funcionalidade também chegou à barra de tarefas via Internet Explorer 4.0 nos anos 90. Você pode acessar as barras de ferramentas ao clicar o botão direito mouse na sua barra de tarefas e expandir “Barras de Ferramentas”. Pessoalmente, gosto de pensar nas Barras de Ferramentas da Área de Trabalho como um tipo antigo de gadget para a plataforma Windows. Ao longo dos anos os desenvolvedores fizeram várias barras de ferramentas, incluindo controles para música de fundo (por exemplo, o modo mini do Windows Media Player mostrado na figura 1), campos de busca, visões mais ricas das baterias de laptops, previsões do tempo e muito mais.

Um dos cenários originais das Barras de Ferramentas da Área de Trabalho era permitir que os clientes iniciassem itens diretamente a partir da barra de tarefas. Na verdade, a própria Inicialização Rápida é um tipo especial de barra de ferramentas que exibe atalhos na pasta da Inicialização Rápida. Você sabia que pode até criar sua própria barra de ferramentas para qualquer pasta no seu computador a fim ter acesso rápido ao seu conteúdo (a partir do menu Barra de Ferramentas, selecione "Nova Barra de Ferramentas" e escolha a pasta à qual você quer ter acesso)? O OS mais recente da Apple introduziu uma funcionalidade semelhante no Dock chamada Stacks. Enquanto acredito que a implementação desse recurso é geralmente mais atraente visualmente, é interessante notar que eles lançaram recentemente uma nova representação de lista que corresponde à nossa funcionalidade original. Parece que nós concordamos que uma lista simples é na verdade a maneira mais eficiente de analisar e navegar vários itens.

Depois de elogiar toda a importância das Barras de Ferramentas da Área de Trabalho, também temos que admitir que elas apresentam vários desafios. Para começar, não são a coisa mais fácil de descobrir. Também ocupam espaço valioso em barras de tarefas já bastante ocupadas. Entretanto, o mais importante é que elas nem sempre atingem os objetivos do usuário. Claro que você pode ter acesso ao conteúdo de uma pasta a partir da barra de tarefas, mas e se os arquivos que você quer acessar não estão num só local? Esses são desafios de desenvolvimento que pretendemos enfrentar.

Área de Notificação: O Murmurador

A Área de Notificação é mais ou menos o que você espera dela - uma área para notificações. Era uma parte original da barra de tarefas e foi desenvolvida para sussurrar informações para o cliente. Nela você pode monitorar o sistema facilmente, ser alertado quanto ao estado de um programa ou até mesmo ver as horas. Os ícones eram a maneira predominante de transmitir informações até que as últimas versões do Windows introduziram balões de notificação que fornecem alertas descritivos com texto. Também foi adicionada uma UI recolhível que escondia ícones inativos a fim de que a barra de tarefas parecesse mais limpa.

Com mais desenvolvedores alavancando sua funcionalidade, a Área de Notificação se tornou mais comum ao longo dos anos. Alguns poderão observar que ela mudou de um simples murmúrio para algo mais alto. Com base nos comentários que coletamos dos clientes, reconhecemos que a Área de Notificação poderia melhorar ao se tornar menos turbulenta e mais controlável pelo usuário final.

Mostrando os Dados

Artigos anteriores neste blog discutiram como os clientes podem nos enviar dados de forma voluntária e anônima sobre como utilizam nossos recursos. Utilizamos esses achados para nos ajudar a direcionar nossos desenvolvimentos. Notem que os dados não desenvolvem os recursos, mas certamente nos ajudam a priorizar nossos investimentos bem como a validar nossa abordagem.

Freqüentemente somos todos culpados de dizer algo como “sabemos que todo mundo faz <x>” ou "todos os usuários fazem <y>".

Considerando a confiabilidade e a exatidão estatística desses dados, podemos falar com mais precisão no mundo real sobre como as coisas são usadas na prática. Vamos analisar algumas informações interessantes que coletamos sobre como nossos clientes utilizam a barra de tarefas.

A Figura 3 oferece alguns dos dados mais importantes sobre a barra de tarefas - contagem de janelas. De forma geral, sabemos que a vasta maioria de nossos clientes abrem até 6 a 9 janelas simultaneamente durante uma sessão (uma sessão é definida como um login/logout ou 24 horas – o que ocorrer primeiro). Nem é preciso dizer que a barra de tarefas deveria funcionar para a distribuição total deste gráfico, mas identificar o "ponto de eficiência" ajuda a concentrar nossos esforços na área que mais importa para a maioria dos clientes. Portanto, sabemos que se resolvermos o caso de 6 a 9 e fizermos um bom trabalho tanto para o cenário de 0 a 5 quanto para o de 10 a 14 teremos abordado quase 90% das sessões típicas.

Fig. 3: Qual o número máximo de janelas abertas ao mesmo tempo?

As Figuras 4 e 5 nos ajudam a entender como os clientes customizam suas barras de tarefas. Provavelmente poderíamos gastar todo um artigo somente em como determinamos as opções que serão expostas. Talvez numa outra oportunidade lidaremos com o paradoxo da escolha e como as opções pressionam o processo de engenharia ao mesmo tempo em que tornam o produto mais divertido para um conjunto de clientes. Até então, vamos ver quais conclusões podemos tirar desses achados. A conclusão mais óbvia é que a maioria dos clientes não altera suas configurações padrão, o que leva somente um clique no botão direito em Propriedades. Por exemplo, pode ser interessante notar com qual freqüência os usuários finais deslocam a barra de tarefas para outras regiões da tela - menos de 2% das sessões têm uma barra de tarefas que não está na região inferior da tela. Também sabemos que uma pequena porcentagem das máquinas desloca acidentalmente a barra de tarefas e com maior freqüência os usuários finais têm dificuldade em desfazer tal estado – apesar de nossos dados não diferenciarem esta situação. Esses dados não significam necessariamente que nós iríamos remover a funcionalidade de reposicionamento, mas sim que poderíamos priorizar investimentos numa barra de tarefas padrão horizontal em detrimento de outras configurações.

Fig. 4: Como as pessoas customizam sua barra de tarefas? O número vermelho indica a porcentagem de sessões nas quais a caixa de seleção correspondente está habilitada.

Fig. 5: Onde as pessoas colocam sua barra de tarefas?

A Figura 6 oferece algumas idéias sobre a Barra de Ferramentas da Área de Trabalho do Windows Media Player. As Diretrizes Windows UX ditam que para criar uma barra de ferramentas na barra de tarefas do cliente é preciso acionar uma Windows Shell API que peça a permissão do cliente. Analisando o uso do Windows Media Player descobrimos que somente 10% das sessões mostram o consentimento do cliente. Ainda mais surpreendente é que somente em 3% das sessões se consegue ver a barra de ferramentas (você ainda precisa minimizar o Media Player para ver os controles). Em outras palavras, 97% das sessões sequer estão se beneficiando dessa funcionalidade! Já que acreditamos que o cenário tem mérito, saberemos analisar alguns designs alternativos. Gostaríamos de apresentar essa funcionalidade a um grupo maior de clientes enquanto nos certificamos de que o cliente permanece no comando de sua experiência.

Fig. 6: Quantas pessoas utilizam a barra de ferramentas do Windows Media? Habilitada significa que usuário consentiu ao uso da barra de ferramentas, visível significa que a barra de ferramentas de fato apareceu na barra de tarefas.

Evolução da Barra de Tarefas

Antes mesmo de que a equipe se sentasse para pensar em idéias sobre como melhorar a barra de tarefas, nós nos preocupamos em respeitar a UI. A barra de tarefas tem quase 15 anos, todos a usam, as pessoas estão acostumadas com ela e muitos a consideram boa o suficiente. Também reconhecemos que se tivéssemos que melhorá-la, não poderíamos introduzir falhas na utilização onde não há nenhuma. Isso automaticamente cria um padrão muito elevado. Procedemos cuidadosamente a primeiro analisar áreas para melhorias.

Aqui estão pequenas amostras de algumas coisas que aprendemos a partir dos nossos dados, que ouvimos de nossos clientes e que observamos nós mesmos. Uma das melhores maneiras de conseguir comentários literais num ambiente de laboratório onde possamos validar os dados instrumentados, mas também adquirir um contexto detalhado através de entrevistas e questionários. Ao construir a engenharia do Windows 7 temos centenas de horas de estudos como esses. Lembrem-se de que isso é somente um olhar rápido sobre alguns dos comentários – esta não é uma lista exaustiva nem está subentendido que nós iremos, ou devemos, tomar uma atitude com relação a todos esses conceitos.

• Por favor, me deixem reorganizar os botões da barra de tarefas! Por favor.
• Às vezes eu clico acidentalmente no botão errado da barra de tarefas e abro a janela errada.
• Seria ótimo se a barra de tarefas abrangesse múltiplos monitores para que eu pudesse ter mais janelas para as quais alternar.
• Nem sempre há texto suficiente na barra de tarefas para identificar a janela que estou procurando.
• Há texto demais na barra de tarefas. (Sim, isso é exatamente o oposto do item anterior – também vimos isso bastante nos comentários do blog).
• Pode levar vários cliques até chegar a alguns programas ou arquivos que eu uso regularmente.
• Ícones de arquivos fixos às vezes são muito parecidos – gostaria de conseguir diferenciá-los melhor.
• O canto inferior direito da minha tela às vezes é muito turbulento. Há muitos ícones pequenos e balões competindo pela minha atenção.
• Como faço para adicionar/remover “X" da barra de tarefas?
• Gostaria que o Windows guardasse seus recursos de forma inteligente e simplificasse sua interface.

Podemos resumir os comentários com alguns princípios:

• Os clientes podem alternar entre janelas com mais segurança e facilidade.
• Itens e tarefas utilizados com freqüência deveriam ser acessíveis aos clientes.
• Os clientes sempre devem se sentir no comando.
• A barra de tarefas deve ter aparência e percepção mais claras.

Esperamos que este artigo ofereça algumas idéias adicionais sobre a barra de tarefas bem como sobre nosso processo de coleta e resposta aos comentários dos clientes. Fiquem ligados para mais detalhes no futuro.

- Chaitanya

Mais Acompanhamento na discussão sobre Alta DPI

Excelente! Que discussão divertida nós estamos tendo sobre Alta DPI. Foi tão enriquecedor que Ryan escreveu um resumo sobre mais uma parte da discussão. Muito obrigado! --Steven

Houve vários comentários postados com relação à alta DPI, junto com algumas discussões animadas. Muito do que foi dito foram bons exemplos de relatos que são consistentes com os dados que nós coletamos. Para as áreas sobre as quais não tínhamos dados, os comentários ajudaram a validar muitas de nossas suposições para esse grupo. Também está claro que algumas áreas desse recurso são confusas e em alguns casos há alguns “mitos" sobre o que é o ideal, o que é possível e o que realmente está lá. Este artigo de acompanhamento é principalmente para resumir o que ouvimos e para fornecer alguns detalhes quanto às áreas que ficaram um pouco confusas.

Aqui está uma lista com nossas principais “suposições”, ecoadas pelos comentários postados:

• A maioria das pessoas ajusta a resolução da tela ou para ver um tamanho de texto maior ou por acidente
• Há um grupo de pessoas que conhece alta DPI e a usa.
• Algumas pessoas preferem uma maior área de tela enquanto outras preferem uma UI maior
• A habilidade de descobrir as configurações DPI é uma preocupação para alguns
• A compatibilidade entre aplicativos é um problema comum, até um “estraga prazeres” às vezes.
• O Dimensionamento do IE é um dos problemas mais importantes (vejam o IE8, que corrige muitos deles!)
• Há muitas complexidades/sutilezas é e muito difícil explicar esse recurso para a maioria das pessoas

Também houve várias áreas um pouco confusas:

• É verdade que se tudo fosse baseado em vetores esses problemas desapareceriam?
• Isso não deveria simplesmente funcionar sem que os desenvolvedores precisassem fazer nada?
• Qual a diferença com relação ao dimensionamento por aplicativo como o zoom do IE?
• A DPI deveria funcionar por calibragem ou por dimensionamento?

A maioria desses tópicos foi discutida de alguma forma nos comentários, mas já que há tanto interesse, decidimos nos aprofundar em algumas questões/assuntos mais importantes.

Gráficos Vetoriais versus Gráficos de Varredura

Sempre há a esperança com os PCs de que surja uma tecnologia "simples e garantida" que resolva todos os problemas tornando a vida de todos os usuários, desenvolvedores e designers mais fácil. Por exemplo, alguns dos comentários no artigo original sugeriram que se nós fizéssemos o OS totalmente baseado em vetores, esses problemas de dimensionamento desapareceriam. Acontece que há vários problemas em utilizar gráficos vetoriais que não valem a pena explicar.

O primeiro problema é que, às vezes, quando um ícone é pequeno é melhor usar uma representação alternativa a fim de que o significado permaneça claro. Vejam os ícones abaixo. Nesse caso, o designer escolheu uma visão não-perspectiva para o ícone quando ele é mostrado em seu menor tamanho.

Isso acontece porque o designer achou que a informação passada pelo ícone seria mais clara com uma visão direta no menor tamanho. Aqui está outro exemplo ilustrando esse ponto:

Claro, isso significa que o designer deve criar múltiplas versões de design da imagem fonte, então há uma complexidade adicional. A questão aqui é que existe uma compensação a ser feita esta compensação nem sempre é evidente.

Mesmo quando uma fonte vetorial é utilizada, é comum fazer adaptações de tamanho a fim ter a certeza de que o resultado corresponde ao que o designer tinha em mente.  Imagine um gráfico vetorial que possui uma linha de 1 pixel a 128x128 que seja reduzida pela metade para 64x64. A tela não tem como mostrar uma linha perfeita de 1/2 pixel! Em muitos casos, a resposta é que o processador irá “arredondar” para uma linha pixel próxima. Entretanto, fazer isto inerentemente altera o layout dos sub-elementos da imagem. Há também a questão: “para qual linha de pixel arredondar?”. Se o designer não ajustar à mão o material fonte, ficará a cargo do mecanismo do processador tomar essa decisão, e isso pode resultar em efeitos indesejáveis. Poderíamos dizer que isso deve portanto definir regras sobre quais elementos devem ser utilizados num vetor, mas isso somente restringe quais conceitos podem ser representados.

Acontece que até as fontes TrueType que usamos no Windows são ajustadas à mão com informações de tamanho a fim de dar ao resultado a mais alta qualidade possível. A maioria dos pipelines de processador TrueType é baseada em dimensionamento algorítmico de uma fonte vetorial, mas são "dicas" tamanho-dependentes e codificadas à mão em TrueType as quais o designer especifica para orientar o sistema sobre como lidar com casos extremos, tais como linhas ficando entre fronteiras de pixels. Aqui está um link que descreve isso em mais detalhes: http://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx

Não é verdade que gráficos vetoriais são necessariamente menores em tamanho (especialmente para imagens pequenas). A maioria dos designers cria gráficos usando um editor que constrói uma imagem utilizando várias camadas de desenhos e efeitos. Com gráficos baseados em bitmaps, os designers “achatam” as camadas antes de adicioná-las a uma parte de um software. Hoje a maioria dos designers presta pouca atenção ao tamanho das camadas porque o processo de achatamento essencialmente as converte num tamanho fixo com base na resolução da imagem. Com gráficos vetoriais, não há tal técnica de achatamento, então os designers precisam pensar cuidadosamente nas ferramentas que utilizam e os efeitos que eles adicionam para ter certeza que o ícone não vai ficar extremamente grande. Passei algum tempo com um de nossos designers, o qual tinha uma fonte gráfica vetorial para um de nossos bitmaps no Windows e o arquivo tinha 622k! Claro que o tamanho do arquivo é fixo independentemente da resolução final, mas aquele arquivo enorme fica achatado num bitmap PNG de 23k.

Claro que sua representação à mão baseada em vetores provavelmente poderia ser diminuída se as restrições de tamanho fossem parte do processo de tempo do design. Mas essa seria uma restrição adicional para o designer, uma que teriam que aprender a realizar bem.

Como podemos ajudar os programadores?

Para aplicativos que precisam controlar cuidadosamente o layout e parte gráfica, ou dimensionar a fidelidade das imagens com base na resolução disponível, é importante ter uma maneira de determinar localizações de pixels específicas de itens para obter o melhor resultado. Isso é tão verdadeiro para o Mac quanto para o PC (ver http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/). Às vezes há uma crença de que se nós fornecêssemos as ferramentas certas ou a estrutura certa, então todos esses problemas desapareceriam. Todos nós sabemos que cada grupo de ferramentas e cada estrutura têm seu próprio conjunto de compensações (sejam elas Win 32, .net ou HTML). Apesar de não haver uma solução completa e simples, existem coisas que podemos fazer a fim de que escrever aplicativos sensíveis a DPI seja mais fácil para os desenvolvedores. Por exemplo, existem dois importantes eventos futuros do ecossistema nos quais falaremos em detalhe sobre Alta DPI. Também teremos materiais que disponibilizaremos para programadores e que ajudarão a informá-los sobre como converter aplicativos existentes para que reconheçam DPI. O primeiro evento é a Conferência de Desenvolvedores Profissionais da Microsoft, onde falaremos sobre Alta DPI como parte da palestra “Escrever um Aplicativo de Destaque em Hardwares Modernos de Elementos Gráficos" (link). O segundo é a Conferência de Engenharia de Hardware Windows, na qual iremos discutir Alta DPI como parte do evento “Elementos Gráficos e Mídia de Alta Fidelidade" (link).

Ajuda com Problemas de Compatibilidade de Aplicativos

Houve vários artigos sobre compatibilidade de aplicativos e alta DPI (por exemplo, o comentário de bluvg). Também houve comentários discutindo a complexidade e inteligibilidade da configuração Alta DPI. Em alguns casos, os problemas de compatibilidade entre aplicativos podem ser atenuados ao habilitar ou desabilitar o recurso de dimensionamento automático. Isso pode ser alterado globalmente ao ir até a UI DPI, clicar o botão de nome “Personalizar DPI” e alterar a caixa de seleção de nome “Usar escala DPI do estilo do Windows XP”. Quando essa caixa de seleção não está selecionada, os aplicativos que não reconheçam a DPI são automaticamente dimensionados pelo gerenciador de janelas. Quando está selecionada, o dimensionamento automático fica globalmente desabilitado. É interessante notar que para configurações de DPI < 144 DPI, essa caixa está selecionada de forma padrão; para configurações de DPI >= 144 o padrão é não estar selecionada. Em alguns casos, alterar as configurações padrão pode resultar numa experiência melhor dependendo dos aplicativos que você usa e de sua configuração de DPI. Também é interessante notar que o dimensionamento automático pode ser desligado individualmente por aplicativo utilizando as propriedades da Compatibilidade de Programas do Vista. Aqui está um link com mais informações sobre como fazer isso: http://windowshelp.microsoft.com/Windows/en-US/help/bf416877-c83f-4476-a3da-8ec98dcf5f101033.mspx. (Veja a seção sobre “Desativar dimensionamento da exibição em configurações de DPI alto”).

Qual a diferença entre dimensionamento DPI e por aplicativo (como o zoom do IE)?

Um aplicativo UI típico é possui uma janela de conteúdo e um quadro de UI. O quadro de UI é onde os itens do menu e botões da barra de ferramentas estão. A janela de conteúdo é o “modo de exibição do documento”. Por exemplo, no IE a janela de conteúdo é a página da web efetiva. Acontece que o código necessário para dar suporte ao dimensionamento em Alta DPI para as janelas de conteúdo é o mesmo código necessário para fazer o recurso de zoom. Na verdade, para a janela de conteúdo o IE8 simplesmente utiliza a configuração de Alta DPI para configurar o fator de zoom padrão (ver Dimensionamento DPI e Internet Explorer 8 para mais detalhes). Entretanto, a Alta DPI tem o efeito colateral adicional de dimensionar o tamanho do quadro de UI. Já que a maioria das pessoas utiliza o recurso de dimensionamento para aumentar o texto e torná-lo mais legível, faz sentido dimensionar o quadro de UI também, já que o texto nos itens do menu e dicas de ferramentas da barra de ferramentas também será dimensionado. De certa forma, se houver um dimensionamento por aplicativo que se trate realmente da área de conteúdo; os aplicativos darão suporte a isso conforme os desenvolvedores observarem a necessidade do cliente. O dimensionamento DPI faz com que os elementos UI de todos os aplicativos pareçam semelhantes.

A DPI não deveria ser utilizada para calibrar a tela (de forma que "uma polegada é uma polegada")?

Alguns sugeriram que nós simplesmente deveríamos usar a Alta DPI como uma forma de calibrar a tela a fim de que o tamanho físico de um objeto seja o mesmo independentemente da exibição. Isso faz muito sentido de uma perspectiva lógica. A idéia seria calibrar a exibição a fim de que “uma polegada seja uma polegada”. Pensamos em fazer isso, mas o problema é que não resolve a necessidade do usuário final de querer ter uma forma de configurar o tamanho do texto e da UI. Se então nós tivéssemos uma “escala global” separada e variável, isso significaria que os desenvolvedores de aplicativos precisariam prestar atenção em ambas as métricas, o que aumentaria a complexidade para os desenvolvedores. Além disso, se um usuário achar que a UI é pequena demais, quem deveria ajustar a preferência quanto ao tamanho da UI: o desenvolvedor ou o usuário? Em outras palavras, se o designer quer que o botão tenha uma polegada, mas o usuário quer que o botão tenha 1,5 polegadas para que seja mais fácil de usar, quem deveria decidir? Da forma que o recurso funciona hoje, fica a cargo do usuário ajustar sua preferência, mas cabe ao desenvolvedor do aplicativo assegurar que a preferência do usuário seja respeitada.

Mais uma vez, é muito bom ver tanto interesse na Alta DPI. Nós certamente temos alguns desafios à nossa frente, mas de muitas maneiras parece que o ecossistema está pronto para esse desafio. Esperamos que este artigo de acompanhamento tenha ajudado a consolidar alguns dos comentários que recebemos sobre o artigo anterior e a explicar algumas das complexidades desse recurso em maior detalhe.

--Ryan Haveson

Acompanhamento sobre resolução de alta DPI

Um dos resultados legais desse diálogo é ver como há interesse em aprofundar-se nos detalhes e dados por trás de alguns dos tópicos, conforme foi dito nos comentários e emails. Estamos nos divertindo ao discutir de forma mais profunda essas questões e observações. Este artigo é um acompanhamento aos comentários sobre alta resolução DPI, compatibilidade entre aplicativos e os problemas gerais com legibilidade em muitas situações. Gostaria de apresentar um gerente de projetos que lidera nossa equipe de Elementos Gráficos da Área de Trabalho; ele vai dar mais informações quanto a nossa discussão sobre elementos gráficos e Windows 7. –Steven

Quando começamos a planejar o Windows 7, analisamos dados dos clientes quanto a hardware de exibição e descobrimos algo muito interessante (e surpreendente). Descobrimos que mais ou menos a metade dos usuários não configurava seus PCs para utilizar a resolução total de tela nativa. Aqui está uma tabela representando os dados que obtivemos do Programa de Feedback do Windows do qual Christina falou num artigo anterior.

Não temos como saber com certeza por que os usuários ajustam sua resolução de tela reduzindo-a, mas muitos dos comentários que recebemos corroboram nossa hipótese de que muitos fazem isso porque têm dificuldade em ler textos padrão em displays de alta resolução. Tendo dito isso, alguns usuários provavelmente encontram essa configuração por acaso; por exemplo, por causa de um driver de vídeo incompatível num aplicativo que alterou a resolução por algum motivo, mas não retornou à resolução inicial. Independentemente de por que a resolução da tela está mais baixa, o resultado é um texto borrado que pode aumentar significativamente a vista cansada ao ler na tela de um PC por um período prolongado. Em telas de LCD, grande parte do borrão se deve ao fato de que elas são feitas de pixels fixos. Em configurações de resolução não-nativas, isso significa que o sistema deve apresentar pixels fracionários ao longo de unidades fixas, causando um efeito borrado. Outro motivo para a aparência borrada é que quando a exibição não é configurada para resolução nativa não podemos aproveitar de forma adequada nossa Tecnologia ClearType de Processamento de Texto. , a qual a maioria das pessoas (apesar de nem todos) prefere. É interessante notar que a perda de fidelidade devido à alteração da resolução da tela é menos marcante num display CRT do que num display LCD, principalmente porque CRTs não possuem pixels fixos da mesma forma que os LCDs. Entretanto, por causa das vantagens de custo e tamanho e da popularidade do laptop, displays LCD estão rapidamente ganhando participação de mercado na base de usuários. Outro problema ao trabalhar com uma resolução de tela não-nativa é que muitos usuários configuram inadvertidamente a exibição para uma taxa de proporção também não-nativa. Isso resulta numa imagem que além de borrada é distorcida! Como vocês podem imaginar isso exacerba ainda mais os problemas de cansaço da vista.

Analisando além do texto, a fidelidade resultante para a mídia nesses cenários também fica significativamente reduzida. Com a configuração que muitos usuários têm, mesmo se o hardware for capaz não podem ver conteúdo de TV nativo de “alta definição” de 720p ou 1080p, o que corresponde às resoluções de tela de 1280x720 e 1920x1080 respectivamente. O monitor do PC tem sido tradicionalmente o dispositivo de exibição de “alta definição”, mas sem abordar esse problema nós estaríamos arriscando seguir a indústria de TV nesse sentido. Apesar de ser verdade que somente 10% dos usuários possuem hoje uma tela de PC verdadeiramente capaz de mostrar 1080p, conforme essas telas continuem a cair de preço a base de usuários deve continuar a crescer. Podem apostar que haverá uma nova onda de conteúdo de fidelidade ainda mais alta no futuro, a qual os usuários vão querer aproveitar. Por exemplo, quando as exibições atingirem 400 DPI ficarão quase indistinguíveis de texto impresso no papel. Até a geração atual de leitores de eBooks com uma DPI de aproximadamente 170 se parece bastante com um pedaço de papel por trás de um pedaço de vidro.

Isso mostra que aqui há um benefício real a se aproveitar para usuários finais. Existe uma infra-estrutura no Windows chamada “Alta DPI” que pode ser utilizada para lidar com isso. A Alta DPI não é um novo recurso para o Windows 7, mas foi a partir do Vista que a interface do usuário do OS fez investimentos significativos em suporte para alta DPI (além da infra-estrutura presente anteriormente). Para experimentar isso no Vista, clique com o botão direito do mouse em área de trabalho -> personalizar e selecione “Ajustar Tamanho da Fonte (DPI)” na coluna do lado esquerdo. Nosso pensamento para o Windows 7 é de que se habilitarmos a alta DPI logo de início em displays compatíveis possibilitaremos aos usuários ter uma experiência em fidelidade total além de reduzir o esforço da vista de forma significativa ao ler a partir de uma tela. Há até mesmo infra-estrutura disponível para que detectemos a DPI nativa de um display a fim de configurar melhor as configurações padrão iniciais. Entretanto, ao fazer isso também abrimos uma porta para expor alguns problemas com aplicativos que podem não ser totalmente compatíveis com configurações alta DPI.

Um dos problemas é que para que aplicativos GDI reconheçam DPI, o desenvolvedor deve escrever o código para dimensionar o quadro da janela, tamanho do texto, botões gráficos e layout a fim de corresponder ao fator de dimensionamento especificado pela configuração DPI. Aplicativos que não fazem isso podem apresentar alguns problemas. A maioria deles é de pouca importância, como tamanhos de fonte incompatíveis ou artefatos menos importantes no layout, mas alguns aplicativos apresentam grandes problemas quando executados com configurações de alta DPI.

Podemos atenuar algumas coisas no Windows 7, tais como dimensionamento automático para aplicativos que não reconhecem declaradamente DPI (ver o blog de Greg Schechter sobre o assunto), mas até mesmo esses atenuantes apresentam problemas. No caso de dimensionamento automático, aplicativos que não reconhecem DPI são automaticamente dimensionados pelo gerenciador de janelas. O tamanho do texto corresponde à preferência do usuário, mas também introduz como resultado um efeito borrado para a janela daquele aplicativo. Para aqueles que não conseguem ler um texto pequeno sem o dimensionamento, esse é um recurso necessário para tornar a configuração alta DPI útil. Entretanto, outros clientes poderão somente utilizar aplicativos que se ajustem bem numa alta DPI ou que sofram impacto menor de textos incompatíveis e podem achar que o efeito borrado resultante causado pelo dimensionamento automático é uma opção pior. Temos que escolher uma opção padrão já que não há uma maneira de o OS detectar se um aplicativo reconhece DPI ou não. Sempre voltamos à questão de ponderar os benefícios e analisar as compensações. Em longo prazo, a solução é ter certeza de que os aplicativos sabem ser independentes com relação à resolução e são capazes de ajustar-se às preferências desejadas pelo usuário, o que exige suporte de nossas ferramentas e documentação. O desafio para uma plataforma é entender como chegar lá ao longo do tempo e como produzir a melhor experiência possível durante a transição.

Satisfação do cliente em longo e curto prazo

Utilizando o modelo de TV de alta definição, podemos ver que em longo prazo é desejável ter uma experiência de alta fidelidade. O único problema é que apesar de a infra-estrutura de alta DPI existir há vários lançamentos do Windows (na verdade há um artigo MSDN de 2001 sobre como fazer com que aplicativos reconheçam DPI), não temos certeza de quantos aplicativos são realmente testados nessas configurações. Enfrentamos então um impacto negativo em potencial de curto prazo e não-quantificado sobre os clientes causado por habilitar esse recurso de forma mais ampla. A primeira coisa que fizemos foi quantificar a exposição. Fizemos isso através da realização de um teste com mais de 1.000 aplicativos em nosso laboratório de compatibilidade entre aplicativos para ver como se comportariam com configurações de alta DPI. Os resultados que encontramos estão abaixo, os quais mostram a distribuição de problemas ocorridos com esses 1.000 aplicativos.

Uma observação rápida, quando dizemos "erro" queremos dizer qualquer ocasião na qual o software se comporta de forma inconsistente com as expectativas - isso pode ser algo estético ou uma pane. Classificamos a gravidade desses erros numa escala de 1 a 4, na qual Sev 1 é um problema muito grave (tal como uma pane e/ou perda de dados ou funcionalidade) e Sev 4 é um problema bastante sutil e/ou muito difícil de reproduzir.

A maioria dos aplicativos tem bom desempenho em alta DPI e poucos aplicativos têm perda de funcionalidade importante. Claro que não precisamos nos preocupar com aqueles que funcionam bem. Além disso, se 1% dos aplicativos aparentam problemas importantes em alta DPI isso pode ser um número significativo. Portanto nós analisamos os erros e os colocamos em categorias de acordo com o tipo de problema encontrado. Aqui estão nossos resultados:

Descobrimos que um dos problemas mais significativos estava relacionado à UI recortada. Analisando isso mais a fundo, ficou claro que a maioria desses casos ocorreu em configurações nas quais a resolução de tela efetiva era bem baixa (800x600 ou mais baixa). Com base nisso, pudemos desenvolver a UI de configuração de tal forma que minimizamos o número de casos nos quais os usuários configurariam uma resolução efetiva tão baixa. Analisamos as categorias de problemas uma por uma e, quando possível, sugerimos melhoras para cada classificação. Claro que o melhor é prevenir; portanto, a Alta DPI é um objetivo importante para nossas linhas de compromisso de desenvolvedores para PDC, WinHEC e outros locais futuros.

Dados de usuários agregados versus individuais

Algo que podemos observar é que muitos usuários estão aproveitando a Alta DPI atualmente (Vista/XP). Com base nos dados que temos somente uma pequena porcentagem dos usuários está habilitando o recurso Alta DPI atualmente. Isso poderia ser facilmente interpretado como uma mensagem clara dos usuários finais dizendo que não se importam com esse recurso ou que não precisam dele. Uma explicação alternativa poderia ser que a falta de adesão se deve principalmente porque o XP e o Vista somente ofereciam um suporte shell limitado para Alta DPI e a versão do IE que foi lançada com essas plataformas tinha problemas significativos ao exibir tamanhos de fontes incompatíveis e páginas da web mal dimensionadas. Também sabemos através de relatos que há usuários que adoram esse recurso e o utilizaram antes mesmo do Vista. Mais uma vez, temos que interpretar os dados é isso nem sempre fica claro.

A hora certa: será que esse é o recurso certo para o mercado neste momento?

Felizmente, não temos um problema do tipo “o ovo e a galinha”. O hardware já está em campo e no mercado, então é somente uma questão do OS tirar vantagem dele. Do ponto de vista do software, a maioria dos aplicativos de software mais importantes reconhecem DPI (inclusive browsers com zooming melhorado, como o IE 8), mas ainda há alguns aplicativos que podem não se dar bem com Alta DPI. Outra informação importante é que a resolução do display para painéis LCD está alcançando seu máximo no DPI padrão. Para esses displays, não há razão para ultrapassar 1900x1200 sem suporte do OS para Alta DPI, pois o texto ficaria pequeno demais para ler. Além disso, essa resolução já é capaz de reproduzir os vídeos de maior fidelidade (1080p), bem como fotos de 2 megapixels. A combinação entre o hardware existente em campo, oportunidades futuras de ter acesso a melhores experiências e o fato de que o hardware está agora bloqueado no OS e software evidencia que este é o momento certo.

Conclusão

A análise dos dados dos clientes nos ajuda a identificar maneiras de melhorar a experiência do Windows. Nesse caso, vimos claramente que tivemos uma oportunidade de ajudar os usuários a configurar facilmente seu display de forma que pudessem se beneficiar de uma experiência de mídia em alta fidelidade, bem como de textos nítidos apresentados num tamanho adequado. Tendo dito isso, toda vez que investimos num recurso que pode ter um impacto em potencial sobre o ecossistema dos aplicativos Windows queremos ter cuidado ao adiantar os investimentos de vocês em software. Também queremos ter certeza de que nossa comunidade de ISVs estará profundamente envolvida nos estágios iniciais a fim de que possam aproveitar o trabalho sobre plataformas que fizemos para repassar esses benefícios continuamente para seus clientes.  Enquanto isso, os testes internos que fizemos e os dados que coletamos foram extremamente importantes para nos ajudar a tomar decisões informadas ao longo do caminho. A Alta DPI é um bom exemplo de como é preciso que todo o ecossistema participe numa solução e de como podemos utilizar os dados dos clientes em campo, bem como testes internos, para determinar os problemas que as pessoas estão encontrando e para nos ajudar a escolher o melhor caminho a seguir.

 --Ryan

O Programa de Feedback do Windows

Apresentamos Christina Storm, que é gerente de programas na equipe de recursos Engenharia de Clientes do Windows que trabalha com telemetria.

Num artigo anterior, o Steven apresentou as Equipes de Recursos do Windows 7. Eu sou uma gerente de programas que trabalha com telemetria na equipe de Engenharia de Clientes Windows. Nossa equipe cuida do Programa de Feedback do Windows, um de vários programas de feedback em atividade hoje que nos permite trabalhar diretamente com os clientes e torná-los parte de nosso processo de engenharia.

O Programa de Feedback do Windows (WFP) está em atividade há vários anos desde os ciclos de produtos do Windows XP e Windows Vista e nós estamos atualmente nos fortalecendo para deixar todos os aspectos desse programa prontos para o Windows 7. No centro desse programa está um amplo painel de pesquisa com consumidores que se inscreveram através do nosso web site http://wfp.microsoft.com durante o período de inscrições. Os clientes optam por fazer parte de um programa de levantamento de dados, um programa de feedback automático ou ambos. Depois eles respondem a uma pesquisa de perfil de vinte minutos, a qual nos permite posteriormente analisar seus comentários com base em seu perfil. Temos clientes numa ampla faixa de conhecimento sobre computadores em nosso programa e estamos trabalhando constantemente para equilibrar o painel a fim de conseguir clientes de grupos menos representados. A maioria dos clientes que estão dispostos a participar voluntariamente num programa de feedback como o nosso é geralmente entusiasmada com relação a tecnologia. São pessoas que aderiram cedo a produtos eletrônicos de consumo, serviços digitais e novas versões de software. Por outro lado, clientes que vêem o PC como uma ferramenta para realizar um trabalho tendem a ser mais relutantes em participar. Também precisamos de mais participantes do sexo feminino!

Clientes que participam do programa de feedback automático instalam uma ferramenta de coleta de dados desenvolvida pela Equipe de Telemetria do Windows. O acordo de privacidade desse programa descreve a coleta de dados realizada por nossa ferramenta. Aqui estão alguns exemplos:

• Comportamento ao utilizar janelas incluindo aplicativos instalados e utilizados.
• Estruturas de arquivos e pastas em seu computador, incluindo o número de tipos de arquivos nas pastas, tais como o número de arquivos jpg na pasta Imagens.
• Informações específicas do sistema, tais como hardware, dispositivos, drivers e configurações instaladas em seu computador.
• Dados do Programa de Aperfeiçoamento da Experiência do Usuário Windows (CEIP).

A partir dos dados coletados criamos relatórios que são utilizados por várias equipes de recursos Windows, bem como por planejadores e pesquisadores de usuários. O gráfico abaixo mostra a resposta para a seguinte pergunta: Qual o tipo mais comum de arquivo que os clientes que participam de nosso programa armazenam em seus PCs e quais os locais de armazenamento mais comuns?

Os resultados nos ajudam com o planejamento para lidar com os volumes de dados que os clientes armazenam em seus PCs bem como a reproduzir cenários realistas em nossos testes laboratoriais ao configurar os PCs com um número semelhante de arquivos, tamanhos de arquivos e distribuição de arquivos nos PCs.

Essas coletas de dados ainda nos ajudam a criar relatórios com base em perfis de membros do painel. O gráfico acima poderia parecer diferente se o tivéssemos criado com base em dados fornecidos somente por desenvolvedores e então o comparássemos com dados fornecidos somente por jogadores de games, só para citar alguns perfis diferentes que participam de nosso programa. O nível de conhecimento sobre o Windows às vezes também faz diferença. Portanto, é muito importante para nós ter a participação no programa de clientes que se consideram peritos em Windows, assim como de clientes que não gostam de passar muito tempo no PC e que só o vêem como uma ferramenta para realizar outras coisas. Com base nos dados, poderemos decidir otimizar certa funcionalidade para um perfil específico.

Em geral, utilizamos esses dados para entender melhor o que melhorar na próxima versão do Windows. Vamos analisar como a amostra representativa configura seus monitores. Primeiro: quais resoluções são utilizadas pelos clientes em seus PCs? A tabela seguinte lista resoluções típicas e a distribuição com base no Programa de Aperfeiçoamento da Experiência do Usuário do Windows, o qual faz uma amostra de todos os PCs participantes (Notem que a soma não corresponde a 100% porque nem todas as resoluções são incluídas):

Vocês podem notar é que aproximadamente 10% dos clientes está utilizando resolução alta ou maior. Em alguns dos comentários as pessoas perguntavam se nossos dados representavam os usuários “top” ou “avançados”. Dado o tamanho dessa amostra e o número de indivíduos com uma resolução de ponta, acho que é razoável concluir que nós representamos de forma adequada este e todos os segmentos. Essa amostra é uma amostra grande (aqueles que consentiram) de um conjunto de dados enorme (todos os usuários Windows), portanto é estatisticamente relevante para estudos segmentados,

Descobrimos que uma grande porcentagem dos participantes de nosso programa diminui a resolução de seu display da maior resolução possível para ele. Analisando os dados advindos do Programa de Aperfeiçoamento da Experiência do Usuário do Windows para fins de comparação, notamos uma tendência semelhante: mais de 50% dos clientes com resolução de tela de 1600x1200 estão ajustando sua resolução para 1024x768, provavelmente porque acham desconfortável ler o texto pequeno em displays de alta resolução. O efeito negativo dessa alteração de resolução é a perda de fidelidade até o ponto em que ler texto em editores e web browsers fica difícil. Conteúdo de vídeo de alta definição também não será mostrado de forma apropriada.

Aqui estão dos dados para clientes com display com capacidade 1600x1200:

Num artigo futuro do blog, um dos gerentes de programa da Equipe de Elementos Gráficos da Área de Trabalho do Windows irá descrever o que fizemos com essa informação para melhorar a qualidade de exibição e conforto ao ler no Windows 7.

Também usamos freqüentemente nossos dados para selecionar participantes adequados para uma pesquisa. Um pesquisador pode querer mandar uma pesquisa online somente para usuários ativos de aplicativos de máquina virtual. Nós primeiro iríamos determinar tal grupo de usuários analisando nossos dados de “utilização de aplicativos” e então criar a lista de participantes para o pesquisador. Às vezes nós combinamos dados coletados automaticamente com respostas a pesquisas para analisar a relação entre a satisfação geral de um cliente e sua configuração de PC.

Atualmente, 50% dos participantes de nosso painel estão utilizando o Windows XP e 50% estão utilizando o Windows Vista. Atualmente não estamos oferecendo inscrições. Se você tem interesse em ser convidado a participar desse programa, por favor envie um email para winpanel@microsoft.com com o assunto “Notifiquem-me sobre inscrições”. Se você gostaria de incluir algumas informações sobre você, incluindo seu nível de conhecimento sobre o Windows, nós ficaríamos muito agradecidos! Nós o colocaremos na fila de pedidos e faremos o possível para convidá-lo quando pudermos.

Quando lançarmos o Windows 7 beta também coletaremos comentários desse painel e pediremos a participação de um grupo de usuários beta do Windows 7. Nossos planos atuais pedem a adesão para que o beta aconteça da maneira padrão da Microsoft em http://connect.microsoft.com. Fiquem ligados!

-- Christina Storm

Uma reflexão sobre algumas discussões recentes

Quando começamos este blog, a idéia era ter um diálogo: uma conversa de duas vias sobre a engenharia do Windows 7. Não poderíamos estar mais felizes com o modo como as coisas estão acontecendo nesse curto período. De acordo com nosso objetivo, iniciamos uma discussão sobre como construímos o produto e tivemos uma chance de estabelecer uma troca nos comentários e artigos sobre assuntos que claramente são importantes para vocês. Para mostrar alguns números, eu recebi pessoalmente mais ou menos 400 emails (e respondi a vários deles) e no total recebemos aproximadamente 900 comentários em língua inglesa de quase 500 leitores diferentes (alguns de vocês deixaram mais de 10 comentários). Números iniciais mostram que temos mais do que 10 vezes aquele último número em leitores e visualizações de página.

Algumas pessoas no blog pediram mais detalhes sobre como construímos o Windows – qual o processo de seleção dos recursos, o processo diário de construção, globalização, e outros. Mantendo nossa tradição de ver o outro “lado” de uma questão, vários também disseram que já têm informação o bastante sobre isso e querem conhecer os recursos. Portanto, neste artigo quero oferecer uma perspectiva sobre alguns recursos que foram muito discutidos e também uma perspectiva sobre discussão e seleção de recursos.

Adoramos as reações. Vimos que alguns assuntos geraram um fórum para que as pessoas perguntassem bastante sobre os recursos e faremos o máximo para responder dentro do contexto do que nos propusemos a fazer, que é discutir sobre como o Windows 7 é feito, incluindo como fazemos escolhas quanto o que é incluído no produto. Admito que possa ser tentador (para mim) fazer uma enorme lista de recursos e então dizer “façam seus comentários”. É tentador porque eu vi isso antes e é certamente algo fácil e que pode fazer as pessoas mais felizes e mais envolvidas. Entretanto, há alguns desafios apresentados por essa técnica que fazem com que esse tipo de fórum seja um pouco frustrante para todos nós. Primeiro, é baseado em “reações” na medida em que pede que vocês somente reajam àquilo que vêem. Afora o contexto compartilhado, não estaremos falando a mesma língua em termos de motivações, prioridades e outras coisas. Isso é particularmente verdadeiro quando um recurso é prematuro e não somos realmente capazes de "vendê-lo" efetivamente nem de contar sua história. Segundo, um grande conjunto de comentários do tipo relatos (quer dizer, textos livres) não são dados que possam ser realmente utilizados e não apreendem o diálogo e a discussão que estamos tendo. Tomar decisões dessa forma quase certamente não cairá bem com a “metade” das pessoas que não concordam com a decisão ou priorização. Terceiro, há uma tendência de achar que os comentários oferecidos levam a ação naquela direção. Esses são alguns motivos pelos quais escolhemos a abordagem de falar sobre como estamos fazendo o Windows 7.

Alguns sugeriram a publicação de uma lista de recursos e que utilizássemos então um processo de classificação/votação. Na verdade, alguns já chegaram a fazer isso para nós em seus próprios web sites. Obrigado. Esses sites são interessantes e nós realmente os lemos. Acho, porém, que todos concordamos que também há um desafio muito conhecido para muitos, que é quando um grupo auto-selecionado oferece um tipo de comentário que é provavelmente diferente daquele de um grupo que é escolhido intencionalmente como sendo representativo. Estava me lembrando de um episódio antigo de Saturday Night Live, “Larry the Lobster”, no qual ao pagar uma taxa você poderia votar em salvar Larry da panela ou não. Todos sabem que essa é uma pesquisa não-científica, mas também nem sabemos se é uma pesquisa não-científica sobre opiniões quanto aos direitos dos animais ou preferências gastronômicas. Acho que o valor de se votar em recursos específicos vai além de mero entretenimento, mas também temos que nos dedicar a ter certeza de que estamos refletindo sobre os assuntos dentro do mesmo contexto. Também queremos que qualquer amostra de clientes que fizermos seja representativa ou da ampla base de clientes ou do “segmento” alvo específico de clientes.

Portanto, grande parte desse blog se trata de criar um fórum onde possamos nos comunicar sobre o que é importante e quais são os contextos relativos que trazemos para a discussão. É por isso que pensamos nele como um diálogo, e não como pergunta e resposta, solicitação e atendimento, ponto e contraponto ou anúncio e comentário. Pessoalmente, estou me beneficiando genuinamente da natureza dinâmica do que vamos escrever no blog com base nos que participam dele. Portanto, isso é muito mais como uma reunião social para a qual nós vamos a fim de nos encontrar e conversar do que uma reunião de negócios, na qual temos objetivos específicos, ou uma aula de treinamento onde somente uma das partes é responsável por falar.

Nesse sentido, seria bom continuar a conversa sobre alguns pontos que foram levantados com freqüência e acho que as pessoas vêm pedindo um ponto de vista sobre elas. Cada um merece seu próprio artigo, mas eu também gostaria de oferecer um ponto de vista sobre alguns pedidos específicos de recursos. Vamos analisar alguns assuntos que surgiram conforme falamos sobre desempenho ou a experiência geral do Windows. Por esta ser uma “resposta” a comentários e idéias, há a possibilidade de adotarmos a forma de ponto/contraponto; espero que possamos nos lembrar das discussões de "contexto" que tivemos antes de entrarmos mais a fundo no debate.

Instalação baseada em perfis

Em termos de idéias sobre recursos, alguns de vocês sugeriram que nós oferecêssemos uma maneira de configurar o Windows para um cenário específico quando da instalação. Alguns sugeriram cenários como uso de jogos, uso ocasional, para produtividade de negócios, navegação na web, emails, “utilização leve” e outros. Fica subentendido que o Windows poderia funcionar melhor (velocidade, espaço, etc.) se o ajustássemos para um cenário específico de acordo com esses limites, mas na verdade essa suposição provavelmente não seria bem sucedida de forma consistente ou geral. Há muitas maneiras de contemplar esse recurso - pode ser uma na qual adaptamos os conteúdos do Menu Iniciar (algo que os administradores fazem em empresas o tempo todo), ou a métrica de desempenho para alguns componentes de baixo nível (tamanho de bloco de disco, tamanhos de quadro tcp/ip, etc.) ou o nível de refinamento da interface do usuário (também conhecido como alguns chamam de “bonita por fora”), e outras. Vimos o cenário ou instalação com base em funções como um recurso bastante usado no Windows Server 2008. No ambiente do servidor, entretanto, cada uma dessas funções representa um hardware diferente (provavelmente com configurações diferentes) ou talvez um VM específico numa máquina muito robusta, além de também representar “cargas de trabalho” claramente entendidas (servidor de arquivos, servidor de impressoras, servidor de web).

O PC desktop (ou laptop) é diferente porque há somente um PC e as funções não estão tão bem definidas. Somente em casos raros é que o PC é voltado para um único objetivo. Conforme Mike, do planejamento de produtos, disse no blog, a realidade é que vemos muito poucos PCs que executam somente um software específico e em quase todos os estudos que fizemos quase todos os PCs executam ao menos um software que as outras pessoas não executam. Então devemos retirar disso a dificuldade que é rotular um PC como tendo uma função específica. Existem momentos de funções específicas ao usar um PC e para eles o objetivo de um OS é se adaptar bem às cargas de trabalho diferentes. Como somente um exemplo disso no Windows Vista, considere o trabalho de tornar o indexador uma atividade de baixa prioridade usando o novo I/O APIs de baixa prioridade. Sei que alguns disseram que isso é “algo que eu sempre desligo”, mas a realidade é que há um custo direto e depois o trabalho contínuo de indexar é realmente muito baixo. Isso é algo no qual fizemos melhorias significativas para o Desktop Search 4.0 (lançado como um download) e no Windows 7. A realidade é que um OS de finalidade geral deve se ajustar às cargas de trabalho impostas a ele. Sabemos que nem tudo é perfeito e sabemos que muitos de vocês (particularmente os jogadores) buscam extrair cada pequena gota de desempenho. Mas também sabemos que a complexidade e a fragilidade que aparecem ao tentar “ser mais esperto” do que os serviços do sistema central às vezes escondem as melhorias de desempenho que vemos na amostragem mais ampla de clientes. Há uma atmosfera de “caçadores de mitos” na qual poderíamos embarcar – então que tal compartilhar os resultados sistemáticos que vocês conseguiram e então nós falaremos sobre eles nos comentários?

Outro desafio seria desenvolver essa taxonomia. Isso é algo que eu pessoalmente me esforcei muito para fazer no Office 95 e Office 97. Achamos que poderíamos fazer um “assistente” de instalação perguntar a vocês o quanto usavam o Word, Excel, PowerPoint e Access, ou uma taxonomia que perguntasse a vocês sobre suas profissões (advogado, contador, professor). A partir daí descobriríamos não só quais aplicativos mas quais recursos dos aplicativos nós iríamos instalar. Encontramos dois problemas constantes. Primeiro: chegar somente a descritores ou perguntas para "categorizar" as pessoas falhou nos testes de utilização - o problema clássico de quando apresentadas com um leque de escolhas as pessoas escolheriam todas as medianas ou somente ficariam “paralisadas” achando que nenhuma delas serve (as pessoas normalmente não gostam de rótulos). Segundo: sempre tivemos o problema de múltiplos usuários no mesmo PC ou pessoas que alteram as funções ou padrões de uso. Acontece que nossos clientes corporativos aprenderam o mesmo para nós e tornou-se rotina “instalar tudo”; portanto, deu-se início a uma era de instalar todo um pacote de produtos e então o treinamento era utilizado para restringir os cenários de utilização.

O desafio final foi como apresentar isso aos clientes e quando. Essa seqüência de passos, a experiência OOBE (ao utilizar um produto pela primeira vez), é o que você faz quando retira um PC da caixa (a grande maioria dos clientes Windows o recebem dessa forma) ou executa a instalação a partir de um DVD (o cliente do varejo de “produto embalado"). Isso leva ao item seguinte, que é ver a OOBE como um espaço para fazer otimizações de desempenho. Tentar melhorar o desempenho desse passo é definitivamente um desafio e leva ao nosso "contexto" para a experiência OOBE.

Experiência na Primeira Inicialização - “OOBE"

A OOBE é realmente onde os clientes têm o primeiro contato com o Windows num PC novo. Como muitos já leram em críticas de produtos competitivos (com relação aos PCs Windows), os objetivos de experiência que a maioria das pessoas tem estão relacionados a “qual o caminho mais rápido entre abrir a caixa do PC para a web”. Para o Windows 7, estamos trabalhando junto com nossos parceiros OEM para ter certeza de que é possível oferecer a experiência mais eficiente possível. É claro que os OEMs têm muita flexibilidade e oportunidades de diferenciação naquilo que oferecem como parte da instalação de um novo PC; o que nós queremos é ter certeza de que a parte que se refere ao “OS central” seja absolutamente o mínimo necessário para chegar à parte divertida de usar seu PC.

Por si só, esse objetivo seria o oposto de introduzir "perfis" ou "assistentes” para ajudar a avaliar a(s) utilização(ções) pretendidas (quando da compra) para um PC. Isso não significa que um OEM não poderia oferecer tal experiência de perfil, o que daria uma experiência OOBE diferenciada, mas não uma pela qual pediríamos que todos os clientes passassem como parte de uma instalação de “OS central”.

Reconheço que muitos de vocês, como entusiastas de PCs, passaram pela experiência de instalar um PC Linux usando uma das variedades de gerenciadores de pacotes - provavelmente muitas vezes só para fazer com que uma instalação funcionasse direito. Como viram com essas instalações (especialmente como as coisas convergiram recentemente num distribuidor específico voltado para o usuário final), as formas pelas quais você pode produzir um sistema que roda mal excedem as formas pelas quais você pode produzir uma instalação totalmente adequada (para suas necessidades). Na prática, sabemos que muitos componentes acabam dependendo de muitos outros e no fim das contas é um desafio gerenciar e ajustar esse gráfico de dependência, mesmo como um gerenciador de dependência de software (como o Windows Installer). Conseqüentemente, geralmente vemos os clientes se beneficiando de uma ampla base de softwares na máquina, contanto que isso não tenha um custo alto - desenvolver a instalação faz parte do desenvolvimento do produto, de equilibrar a área de cobertura, conexões de arquitetura, confiabilidade do sistema, etc.

Portanto, nosso contexto para a primeira experiência seria o de que não queremos aumentar a complexidade onde menos interessa aos clientes, já que eles querem atingir a emoção de usar seu novo PC. Isso parece um pouco com os vendedores de carros que não lhe entregam a chave até que você se sente e assista a um DVD sobre o carro e depois faça uma inspeção nele - se você for como eu deve estar gritando "me dê as chaves e me deixe sair daqui".  Achamos que os compradores de PCs são mais ou menos assim e nossas pesquisas confirmam isso ao redor do mundo.

Também reconhecemos que existem usuários avançados que podem querer ajustar o sistema em execução por uma variedade de motivos (desempenho, área de cobertura, área de superfície, etc.). Chamamos isso de “Ligando ou Desligando Recursos do Windows”, que é o próximo item do qual vocês falaram.

Recursos do Windows

Se nós fizermos a instalação típica do Windows como uma que tenha basicamente todos os recursos da SKU (unidade de manutenção em estoque) que o cliente comprou, então como fica o cliente que deseja ajustar o que foi instalado e remover alguma coisa? Os clientes podem querer remover alguns recursos porque simplesmente nunca os usam e não querem fazê-lo acidentalmente ou carregar neles o "código" que possam executar. Os clientes podem estar definindo uma função para o PC (caixa registradora) e portanto se certificando de que alguns recursos específicos nunca estejam lá. Há muitos motivos para isso. Há vários lançamentos o Windows já possui a habilidade de instalar ou desinstalar vários recursos que fazem parte dele. No Windows Vista isso se tornou mais robusto conforme os recursos são removidos do sistema em execução, mas também permaneceram disponíveis para reutilização sem o DVD original. Também tornamos a lista de recursos mais longa no Windows Vista.

Para o Windows 7, muitos nos pediram para tornar essa lista ainda mais longa e conter mais recursos. Isso é algo que estamos considerando seriamente para o Windows 7, já que achamos que é consistente com os objetivos de design de "escolha e controle" dos quais vocês já nos ouviram falar bastante com o Internet Explorer 8.0 beta 2.

Claro que enfrentamos o mesmo desafio que as distribuições do Linux têm: a capacidade de remover rapidamente algumas coisas pode causar problemas em outros recursos quando da remoção; você passa por um processo complexo de informar ao cliente sobre essas “dependências” e no fim das contas você acaba sentindo como se tudo estivesse interligado. Em algumas instalações de OS esse conjunto funciona razoavelmente bem porque há uma duplicação dos recursos (você escolhe a partir de vários navegadores de arquivos, vários navegadores web, vários pacotes de office, até várias GUIs). O OS Windows central, apesar de não estar livre de duplicações, não possui esse tipo de configuração. Ao invés disso lançamos uma plataforma à qual os clientes podem adicionar muitos componentes conforme quiserem.

Oferecemos várias ferramentas disponíveis para clientes que desejarem remover, recolocar ou somente evitar o acesso a componentes do Windows:

• Definir os Programas Padrão (ou Definir Acesso e Padrões do Programa). No Vista esses recursos lhe permitem determinar os programas/manipuladores por tipo de arquivo ou protocolo. Isso foi introduzido no Windows XP SP1. No Vista o SYDP foi expandido e esperamos que todos os softwares da Microsoft registrem e empreguem esse mecanismo de forma adequada. Portanto se você quiser ter um programa de email padrão, manipulador padrão para GIF ou um navegador web de sua escolha, essa é a interface do usuário a ser usada. O próprio Windows respeita esses padrões para todos os tipos de arquivo que gerencia.
• Customização do menu iniciar ou diretivas de grupo. Há algum tempo, administradores corporativos vêm criando PCs “baseados em funções” através da customização do menu iniciar (ou até mesmo retornando ao progman – gerenciador de programas) para mostrar somente um grupo específico de programas. Também vemos muito isso em cybercafés hoje em dia. A funcionalidade SPAD leva isso adiante e oferece uma ferramenta de usuário final para retirar acesso a programas de email, navegadores web, media players, programas de mensagem instantânea instalados e tempos de execução de máquinas virtuais.
• Remoção de programas. Às vezes os clientes só querem remover programas. Com discos de capacidade pequena muitos buscaram remover mais e mais do Windows só para caber em SSDs. Eu certamente já vi algumas das pequenas instalações Windows. A ferramenta de suporte para remover códigos do Windows é utilizar o “Ligar e Desligar os Recursos do Windows”. na interface do usuário (no Vista). Há mais de 80 recursos nessa ferramenta nos pacotes premium do Vista hoje.

Muitos querem que a lista de recursos do Windows que podem ser ligados/desligados seja mais longa e houve muitas sugestões no site de coisas que poderiam ser disponibilizadas dessa forma. Isso é mais complexo por causa da plataforma do Windows, isto é, muitos desenvolvedores dependem de várias partes da plataforma Windows e simplesmente “supõem” que elas estão lá. Seja um media player que usa o catálogo de endereços do Windows, um pacote de finanças pessoais que utiliza spool de impressão avançado ou até um navegador totalmente novo que depende de recursos avançados de rede. Esses são exemplos reais de utilizações comuns de APIs de sistema que não parecem facilmente aparentes da perspectiva do usuário final do software.

Alguns exemplos são muito fáceis de ver e você deve esperar que façamos mais com relação a isso, tal como com os componentes de TabletPC. Tenho um PC que é um laptop bem pequeno e, apesar de possuir funcionalidade total de tablet, não é o melhor tamanho para eu fazer bons trabalhos com tinta (prefiro uma tela de 12.1” ou maior e esse PC tem uma de 10”). O código tablet possui uma área de cobertura na memória; na máquina de 1GB se eu remover os componentes tablet ela não tem desempenho melhor. Isso é algo que posso fazer hoje. As pessoas perguntaram pela Galeria de Fotos, Movie Maker, Windows Mail, Windows Calendar... são bons comentários e coisas boas para nós pensarmos para o Windows 7.

Um ponto importante é que a grande maioria das coisas que você remove dessa forma consome muito pouco ou nenhum recurso se você não as está utilizando. Portanto, apesar de você poder reduzir a área de superfície do PC provavelmente não vai obter melhor desempenho dele. Por exemplo, o Windows Mail não lhe atrasa de forma alguma se você não tiver nenhuma conta de email (ou de notícias) configurada. Para ter certeza você poderia ocultar o acesso com SPAD ou só alterar o identificador de protocolo padrão para o de email de sua preferência. Outro exemplo é que você pode só alterar a associação e nunca iniciar a galeria de fotos para imagens se isso for o que você preferir. Isso significa que esses recursos não ocuparão memória.

Essa foi uma oportunidade de continuar nossa discussão sobre como estamos aprendendo a partir das discussões e de alguns pontos específicos que apareceram bastante. Espero que estejamos adquirindo uma visão comum sobre como vemos alguns dos assuntos levantados.

Esse artigo ganhou o recorde em tamanho. Não esperem que isso ocorra com freqüência :-)

--Steven

Organização do Projeto Windows 7

Oi, quem escreve é Jon DeVaan.

Steven falou sobre como organizamos a equipe de engenharia no Windows, o que é um elemento importante de como o trabalho é feito. Outra parte importante é como organizamos o projeto de engenharia em si.

Gostaria de começar com algumas observações rápidas. A primeira é que Steven lê e escreve mais ou menos dez vezes mais rápido do que eu, então não se surpreendam se não virem a mesma distribuição de palavras por aqui. (Fiquem seguros de que eu sou o pensador da dupla :-). Ou talvez eu esteja com ciúmes). A segunda é que queremos continuar a compartilhar os tópicos sobre “como construímos o Windows 7”, já que isso nos dá um contexto compartilhado para quando entrarmos na discussão sobre recursos quando nos aproximarmos de PDC e WinHEC. Queremos falar sobre como estamos construindo o Windows 7, incluindo o que aprendemos a partir do Longhorn/Vista. Todas essas realidades pesam ao tomarmos decisões para o Windows 7.

OK, agora as partes chatas.

Steven fez uma referência da última vez ao livro Segredos da Microsoft, que é uma excelente análise do que eu gosto de chamar versão dois do Sistema de Engenharia da Microsoft. (A versão um incluía fichas de arquivo e “floppy net” e você não quer mesmo saber sobre ela). A versão dois foi bastante útil para a Microsoft por um período bem mais longo do que qualquer um esperava, mas com o aprendizado dado pelo Windows XP, o ambiente de segurança verdadeiramente diferente que surgiu naquela época, e com o Longhorn/Vista, ficou claro que era hora de outra transformação de gerações em nossa abordagem de engenharia dos produtos.

As lições deixadas pelo XP giram em torno do cenário diferente de segurança em nossa indústria. Você pode saber mais sobre como transformamos nosso aprendizado em ação ao ler o Ciclo de Evolução nos Desenvolvimentos em Segurança, que é um conjunto de práticas de engenharia recomendadas pela Microsoft para desenvolver softwares mais seguros. Utilizamos essas práticas internamente na construção do Windows.

Os comentários nesse blog mostram que a qualidade de um sistema completo contém muitos atributos diferentes, cada um de importância variável para pessoas diferentes, e que as pessoas têm opiniões bem diferentes sobre a qualidade geral do Vista. Passo muito tempo lidando com a confiabilidade central do OS e no estudo da telemetria que coletamos de usuários reais (somente com o consentimento destes no Programa de Aperfeiçoamento da Experiência do Usuário). Sei que o Vista SP1 é em geral tão confiável quanto o XP e mais confiável em alguns aspectos importantes. A telemetria nos guiou quanto ao que abordar no SP1. Fiquei feliz de ver uma forma apontada por pessoas que deixaram comentários sobre como o modo de suspensão e retorno está funcionando melhor. Também estou animado com a perspectiva de continuar com os esforços (estamos nos esforçando) para usar a telemetria para tornar o Vista a versão mais confiável do Windows em todos os tempos. Adiciono à lista de qualidades do Vista o fato de que reduz com êxito e quase pela metade as vulnerabilidades de segurança em comparação com o XP. Este blog é sobre o Windows 7, mas você precisa saber que estamos trabalhando no Windows 7 compreendendo profundamente o desempenho do Windows Vista no mundo real.

De formas mais relevantes, as pessoas que nos escreveram e deixaram comentários destacaram oportunidades para melhorarmos o sistema de engenharia do Windows. Desempenho, confiabilidade, compatibilidade e incapacidade de cumprir promessas de novas tecnologias são temas comuns nos comentários. Uma das melhores formas de abordar esses temas é melhorando o gerenciamento diário da engenharia da base de códigos do Windows 7 – ou a qualidade diária de construção. Demos muitos passos concretos para melhorar como gerenciamos o projeto a fim de que tenhamos um desempenho bem melhor nessa dimensão.

Espero que vocês estejam lendo isso e dizendo: “Bem, é óbvio!”, mas minha experiência com projetos de software de todos os tamanhos e em muitas organizações me diz que não é tão óbvio ou facilmente atingível quanto desejamos.

Qualidade de Compilação Diária

Qualidade diária é muito importante num projeto de software porque tomamos decisões todos os dias com base em nosso entendimento de quanto trabalho ainda resta. Quando a compilação média diária é de baixa qualidade, é impossível saber quanto trabalho resta e você toma várias decisões de engenharia ruins. Conforme o número de engenheiros contribuintes aumenta (porque queremos fazer mais), a importância da qualidade diária aumenta rapidamente, já que o fardo da integração aumenta de acordo com a probabilidade de erro de qualquer um dos programadores. Esse problema é mais do que somente não saber qual o número de erros no produto. Se esse fosse o único problema então pelo menos cada programador teria seu destino em suas próprias mãos. O efeito colateral mais maléfico é quando os desenvolvedores não têm segurança suficiente para integrar todas as alterações diárias ao seu trabalho pessoal. Aparecem muitos erros, incompatibilidades e outros problemas desconhecidos quando isso acontece porque as alterações de código nunca foram agrupadas numa máquina.

Preparei um gráfico para ilustrar o fenômeno utilizando uma fórmula simples de prever as falhas de construção causadas por uma taxa de erro de 1 em 100 por parte de programadores distintos numa faixa de tamanhos de grupos (linha azul). Uma taxa de erro de um por cento é boa. Se utilizássemos um taxa típica seria um pouco pior do que isso. Incluí duas outras linhas mostrando a probabilidade de falha de compilação se diminuirmos a taxa média de erro individual pela metade (linha vermelha) e em um décimo (linha verde). Vocês podem ver que mecanismos que melhoram a qualidade diária de cada engenheiro têm grande impacto sobre a qualidade diária geral de compilação.

Para uma equipe do tamanho da do Windows, é um feito e tanto fazer com que as compilações diárias sejam confiáveis.

Nossa melhoria no Windows 7 alavancou outra grande melhoria no sistema de engenharia do Vista: investimento numa infra-estrutura de automação de testes comum em todas as equipes de recursos do Windows. (Você vai ver aqui que há uma ligação inevitável entre os próprios processos de engenharia e a organização da equipe, uma ligação que muitos não reconhecem). Utilizando essa infra-estrutura, podemos verificar as alterações de código fornecidas por todas as equipes de recursos antes de serem incorporadas à compilação diária. Dentro da equipe de recursos essa infra-estrutura pode ser usada para verificar as alterações de código de todos os programadores todos os dias. Vocês podem ver no gráfico como a média de 40 programadores por equipe de recursos está em equilíbrio com a probabilidade de falha de compilação de forma que dentro de uma equipe de recursos a compilação falha de forma relativamente rara.

Para o Windows 7 tivemos bastante sucesso em manter a compilação com nível de qualidade alto todos os dias. Apesar de termos falhas ocasionais, conforme integramos o trabalho de todos os desenvolvedores a automação nos permite encontrar e corrigir quaisquer problemas e produzir uma compilação de alta qualidade virtualmente todos os dias. Venho utilizando o Windows 7 em minha vida diária desde o início do projeto com relativamente poucas dificuldades. (Sei que muitos estão ansiosos para se juntar a mim na utilização de versões do Windows 7 todos os dias – agüentem firme!).

Só por diversão incluí duas fotos de nosso laboratório de compilações onde testes de compilação e verificação para servidores e clientes estão sendo realizados 24 horas por dia:

Conclusão

Nossa! Parece que corremos com um assunto profundo para o qual dedico muito tempo, mas espero que tenham achado interessante. Espero que comecem a entender através desse exemplo que temos sido bastante holísticos no pensamento buscando novas maneiras de trabalhar e melhorias no processo de engenharia do Windows. O teste mais importante para nosso pensamento será a qualidade do produto em si. O que vocês acham dessa questão importante de engenharia de software?

Planejamento de Produtos no Windows: para onde os seus comentários realmente vão?

Nota do Editor: Gostaria de apresentar Mike Angiulo, que lidera a equipe de Ecossistema PC e Planejamento do Windows.  A equipe de Mike trabalha junto com todos os nossos parceiros de hardware e software e lidera os esforços de planejamento e pesquisa de produtos da equipe de engenharia para cada nova versão do Windows. --Steven

No Windows temos uma grande variedade de mecanismos para aprender sobre nossos clientes e mercado, todos os quais têm um papel a nos ajudar a decidir o que construímos. Desde as questões distintas que nossos engenheiros vão responder na WinHEC e PDC até os milhões de registros em nossos sistemas de telemetria, temos ferramentas para responder a quase todo tipo de questões quanto ao que vocês querem que seja construído no Windows e como tudo está indo. Ouvir todas essas vozes juntas e construir um plano coerente para todo um lançamento de um sistema operacional é um desafio bem grande - pode parecer como anotar um pedido de pizza para um bilhão dos seus amigos mais próximos!

Não deve ser surpresa que a fim de organizar o aprendizado precisamos ter uma organização dedicada a ele. Esta é liderada por nossa equipe de Planejamento de Produtos, um grupo de uns vinte e poucos engenheiros que tanto é organizada quanto senta com os gerentes de programa, desenvolvedores e testadores nas equipes de recursos. Eles trabalham durante o ciclo do produto para ter certeza de que nossa visão é convincente e baseada num entendimento profundo do ambiente de nossos clientes, além de estar equilibrada com as realidades empresariais e pressões competitivas que estão em fluxo constante. Durante os últimos dois anos tivemos uma equipe de vinte e poucos pesquisadores profissionais fazendo pesquisas de campo, ouvindo grupos focais e analisando dados de telemetria e de utilização de produtos antes e durante o desenvolvimento do Windows 7 – e ainda não terminamos. Desde nossa pesquisa de mercado independente até a leitura dos comentários de vocês neste blog, continuaremos a refinar nosso produto e como falamos sobre ele com clientes e parceiros. Isso não significa que todos os desejos serão atendidos! Uma das partes mais difíceis de planejar é transformar todos esses dados em planos executáveis para desenvolvimento. Há três trocas difíceis que fizemos recentemente.

A primeira é o que eu vejo como o ‘desafio do teste do gosto'. Há mais de trinta anos esse conceito foi introduzido numa guerra famosa entre duas colas. Lembram da Nova Coca? Foi o resultado de enfatizar demais a resposta bem inicial a um produto com relação à satisfação do cliente em longo prazo. Encaramos esse tipo de desafio o tempo todo com o Windows: como equilibrar a necessidade do produto ser acessível com a necessidade de desempenho durante seu ciclo de vida? Você quer algo que só tenha uma inicialização tão rápida quanto possível ou algo que o ajude a começar? Claro que podemos levar isso aos dois extremos e vocês podem dizer que o fizemos – fomos de c:\  até Microsoft Bob em somente uma década. Encontrar o equilíbrio entre um produto que é novo, recém saído da caixa e continua a mostrar desempenho ao longo do tempo é algo contínuo. Temos etnógrafos que realizam pesquisas que às vezes começam ainda antes do ponto de compra e continuam por meses com visitas periódicas para entender como impressões iniciais se transformam em padrões de uso durante todo o ciclo de vida de nossos produtos.

Em segundo lugar, estamos sempre tentando evitar tomar 'a parte pelo todo'. Com isto eu quero dizer encontrar o equilíbrio apropriado entre dados agregados e de usuários distintos. Um argumento clássico sobre os PCs sempre foi o de que um subgrupo limitado de ações compromete uma grande porcentagem dos casos de uso. O argumento resultante é que um dispositivo de função limitada representaria uma experiência mais simples e mais satisfatória para uma grande porcentagem de clientes! Claro que é possível apontar as falhas desse argumento tanto a curto como em longo prazo. Em longo prazo esse ‘caso de uso comum’ mudou de digitação e impressão para consumo e gravação de CDs, jogos e navegação e continuará a evoluir. Até em curto prazo estudamos a utilização de milhares de máquinas (obviamente com o consentimento dos usuários) e sabemos que apesar de muitos dos padrões de utilização comuns serem na verdade comuns, quase todas as máquinas que já estudamos tinham um ou mais aplicativos únicos em uso que não eram compartilhados por outras máquinas! Esse fenômeno de cauda longa é muito importante porque se nós estivéssemos voltados para o "caso geral" acabaríamos não satisfazendo ninguém. Essa compensação entre escolha e complexidade é uma que se beneficia diretamente de uma abordagem rigorosa com relação ao estudo da utilização tanto coletiva quanto individual sem perder nenhuma das duas de vista.

A terceira diz respeito ao momento certo. Escolher o momento certo é muito importante. Temos um processo contínuo de aprendizado num mercado bastante dinâmico, um que é diretamente influenciado pelo que construímos. O objetivo principal é oferecer a melhor experiência com software e hardware para os clientes: os produtos certo na hora certa. Vimos o que acontece quando esperamos demais para lançar suporte de software para uma nova categoria (deveríamos ter feito melhor com a experiência de padrão de emparelhamento Bluetooth) e o que também acontece quando lançamos software para o qual o restante do ecossistema ainda não está pronto. Esse problema tem a dimensão de se trabalhar para converter tecnologias que sabemos que estão chegando, acompanhar padrões de competição, observar a evolução de cenários de usuários e tentar coordenar nosso suporte de software ao mesmo tempo. Chamar isso de um alvo em movimento não é o bastante! É difícil explicar por que estamos recebendo comentários constantemente, mesmo após qualquer versão do Windows estar pronta.

Essas três compensações explícitas sempre geram conversas animadas – vejam só os comentários feitos até hoje neste blog! Claro que reagir a todas essas necessidades enunciadas é obrigatório num mercado tão dinâmico e desafiador como o nosso. Ao mesmo tempo temos que fazer a maior compensação de todas: equilibrar o que vocês estão pedindo hoje com o que achamos que vão pedir amanhã. Esse é o desafio de definir as necessidades não enunciadas. Todas as indústrias de tecnologia enfrentam essa compensação, seja com o nome de necessidade de inovar versus ajustar ou aderir à noção de curva S de descontinuidades. Por que duas empresas de automóveis bem sucedidas, ambas com os mesmos dados sobre o mercado, lançariam o primeiro Hummer comercial e o primeiro Prius híbrido no mesmo ano? Não é que 1998 tenha sido confuso, é que as demandas de mercado de curto prazo e as de longo prazo não estavam obviamente alinhadas. Ambas as forças estavam visíveis, mas foram rapidamente descartadas: a necessidade de aumentar a capacidade off road para lidar com os estacionamentos de shoppings lotados no subúrbio e a implosão ambiental iminente prevista nos campi de faculdades ao redor do mundo. Temos que equilibrar coisas como essas o tempo todo. Como oferecer compatibilidade com versões anteriores e capacidade futura em cada um dos lançamentos? Será que a tendência de 64 bits vai ser guiada por cenários de aplicativos ou pelas máquinas de 4GB sendo vendidas no varejo?

Temos dados sobre compensações importantes. Temos uma postura quanto a tendências futuras. Isso é normalmente suficiente para começar a próxima versão do produto e permanecemos em contato com os clientes e parceiros durante o desenvolvimento para manter nosso planejamento consistente com nosso direcionamento inicial, mas isso não é suficiente para saber que estamos prontos para lançar. Terminar de verdade sempre exigiu alguma fase posterior de comentários sobre engenharia, sejam ela uma Visualização Técnica da Comunidade, Programa de Adoção de Tecnologia ou um tradicional Beta público. As origens dos testes Betas e até a definição atual do termo não estão claros. Hoje em dia alguns produtos parecem ficar no Beta para sempre! Trabalhamos para definir o melhor momento possível para compartilhar o produto e coletar comentários finais. Se o lançarmos cedo demais normalmente não está pronto para ser avaliado, especialmente com relação a desempenho, segurança, compatibilidade e outros aspectos fundamentais. Se o lançarmos tarde demais não podemos realmente levar em conta nenhum dos comentários que vocês nos enviam e não posso pensar numa receita pior para a satisfação do cliente do que pedir comentários e sistematicamente ignorá-los. Eu estava dando uma olhada num outro site de “comentários” de software onde um monte de comentários pedia à empresa: "por favor, leiam este site!”. Para o Windows 7 vamos lançar um Beta que ofereça uma experiência boa o suficiente e nos permita ter tempo de abordar áreas que precisam de maior refinamento. Este blog será uma parte importante do processo porque fornecerá explicações, conteúdo e orientações suficientes para ajudar vocês a entender os graus de liberdade restantes, algumas das suposições centrais de cada área e dará estrutura a nosso diálogo a fim de que possamos ouvir e responder a quantos comentários vocês queiram deixar. Parte disso vai resultar em erros que serão corrigidos, parte vai resultar em erros de drivers ou aplicativos que ajudaremos nossos parceiros a corrigir. É claro que às vezes nós vamos acabar tendo somente um debate saudável, mas mesmo nesse caso estaremos nos comunicando, vamos responder a comentários construtivos, erros e idéias e vamos começar essa conversa com mais contexto do que nunca. Portanto, por favor continuem mandando comentários. Por favor, participem do Programa de Aperfeiçoamento da Experiência do Usuário. Deixem seus comentários na WinHEC e PDC e nos grupos de notícias e fóruns – nós estamos ouvindo!  

Obrigado,

- Mike

Desempenho de Inicialização

Nota do Editor: Este é o primeiro artigo de um membro nos cargos mais altos na equipe de desenvolvimento. Gostaria de apresentar Michael Fortin, que é um dos Engenheiros Distintos da Microsoft e lidera a equipe de recursos Fundamentais, parte de nosso grupo de Sistema Operacional Central. Michael lidera trabalhos sobre desempenho e confiabilidade através da plataforma Windows. --Steven  (PS: Visitem www.microsoft.com/ie e testem o lançamento beta 2 do Internet Explorer 8).

Temos uma equipe dedicada no Windows 7 voltada para desempenho de inicialização, mas a realidade é que o esforço se estende por toda a divisão Windows e além. Nossos principais parceiros de hardware e software estão trabalhando de perto conosco e podem honestamente ser considerados uma extensão da equipe.

A inicialização pode compreender uma de três experiências: inicialização, retorno do modo de suspensão ou retorno do modo hibernar. Apesar do retorno do modo de suspensão ser o padrão, geralmente durando de 2 a 5 segundos com base em hardwares comuns e carregamento de softwares padrão, este artigo trata primariamente de inicialização, já que se comentou bastante sobre essa experiência. Para o Windows 7, um dos principais objetivos é aumentar significativamente o número de sistemas que possuem bons tempos de inicialização. No laboratório, um sistema muito bom é um que inicializa em menos de 15 segundos.

Para que um PC inicialize rápido é preciso que várias tarefas sejam realizadas de forma eficiente e com alto grau de paralelismo.

• Arquivos devem ser lidos na memória.
• Serviços do sistema têm que ser inicializados.
• Dispositivos têm que ser identificados e iniciados.
• As credenciais dos usuários precisam ser autenticadas para o login.
• A área de trabalho precisa ser construída e exibida.
• Aplicativos de inicialização precisam ser iniciados.

Por causa da diferença entre sistemas e configurações, os tempos de inicialização podem variar significativamente. Isso é verificado por muitos resultados de laboratório, mas também pode ser visto em análises independentes, como a conduzida por Ed Bott. Amostras de dados da população de sistemas de Ed mostraram que somente 35% das inicializações levaram menos de 30 segundos para dar o controle ao usuário. Apesar dos dados de Ed representarem uma população pequena, estão bem alinhados com o que estamos observando. Dados do Windows Vista SP1 (abaixo) também indicam que aproximadamente 35% dos sistemas inicializam em 30 segundos ou menos, enquanto 75% inicializam em 50 segundos ou menos. Os dados do Vista SP1 são dados de telemetria do mundo real. Eles chegam até nós através do grande número de sistemas (milhões) nos quais os usuários optaram por enviar dados anônimos para a Microsoft através do Programa de Aperfeiçoamento da Experiência do Usuário.

Do nosso ponto de vista, pouquíssimos sistemas inicializam de forma consistente e rápido o suficiente e nós temos que melhorar muito. Obviamente os sistemas que ultrapassam 60 segundos têm algo que precisamos melhorar drasticamente – sejam problemas de dispositivos, sistema de rede ou software. Como podem ver há sistemas com tempo de inicialização muito longo. Uma das coisas que vemos no espaço do PC é essa variabilidade de desempenho – a variabilidade surge da diversidade de escolhas e também da diversidade de qualidade dos componentes numa experiência PC qualquer. Também há algumas tarefas de manutenção do sistema que podem contribuir para tempos de inicialização longos. Se um usuário opta por instalar uma atualização de software grande, a atualização do sistema em si pode ocorrer na próxima inicialização. Nossa métrica vai capturar isso e infelizmente pode levar minutos até a conclusão. Independentemente da causa, grande parte do trabalho que precisamos fazer como membros do ecossistema do PC é abordar o tempo longo de inicialização.

Tanto na amostra de Ed quanto nos nossos dados de telemetria, o tempo de inicialização deve refletir quando uma máquina está pronta e responsiva ao usuário. Isso inclui registrar-se no sistema e chegar até uma área de trabalho utilizável. Não é uma métrica perfeita, mas uma que capta a grande maioria dos problemas. Nos sistema do Windows 7 e Vista, a métrica é captada automaticamente e armazenada no registro de eventos do sistema. O artigo de Ed se aprofunda nesse assunto.

Sabemos que há outras noções as quais os usuários julgam refletir o tempo de inicialização, tal como quando o disco pára, quando seus aplicativos respondem totalmente ou quando o menu iniciar e a área de trabalho podem ser utilizados. Além disso, o tempo “Pós-Inicialização” (quando aplicativos no grupo de inicialização e alguns serviços atrasados são executados), o período antes do qual a inicialização do Windows começa e o tempo BIOS podem ser significativos. Em nossos esforços não perdemos de vista aquilo que os usuários consideram como sendo representativo da inicialização.

Antes de discutir alguns de nossos esforços quanto ao Windows 7, gostaríamos de destacar que há um envolvimento considerável com nossos parceiros. Ao verificar dezenas de sistemas encontramos várias oportunidades de melhorar e fizemos alterações. Para ilustrar isso, considerem os dados seguintes retirados de um sistema real. Conforme o sistema chegou até nós, a configuração do produto recém-adquirido apresentou um tempo de inicialização de aproximadamente 45 segundos. Uma instalação simples do Vista SP1 no mesmo sistema produziu um segundo tempo consistente de instalação de aproximadamente 23 segundos. Claro que, em se tratando de uma instalação simples, houve muito menos processos, serviços e um conjunto ligeiramente diferente de drivers (principalmente as versões eram diferentes). Entretanto, pudemos pegar a configuração do produto novo e otimizá-la para produzir um tempo de inicialização consistente de aproximadamente 21 segundos, mais ou menos 2 segundos mais rápida do que a instalação simples porque algumas alterações de driver/BIOS puderam ser feitas na configuração otimizada.

Para este mesmo sistema, vale notar que o retorno do modo de suspensão é de aproximadamente 2 segundos, atingindo uma experiência quase instantânea. Encorajamos que os usuários escolham o modo de suspensão como uma alternativa à inicialização.

Como um exemplo de esforço do Windows 7, estamos trabalhando bastante com serviços de sistemas. Queremos reduzir drasticamente seu número, bem como reduzir suas demandas de CPU, disco e memória. Nossa perspectiva quanto a isso é simples: se um serviço não é absolutamente necessário, não deveria estar iniciando e deveria haver um gatilho para lidar com estados raros a fim de que o serviço só opere nestes casos.

Claro que os serviços existem para completar as experiências de usuário, mesmo as incomuns. Considere a situação onde um teclado, mouse ou HW tablet é adicionado ao sistema enquanto este estava desligado. Se este novo HW não for detectado e drivers não forem instalados para fazer com que ele funcione durante a inicialização, então é possível que o usuário não possa colocar suas credenciais e fazer seu login na máquina. Para um usuário qualquer, isso pode ser muito raro ou nunca acontecer. Para uma população de centenas de milhões de usuários, isso pode acontecer o suficiente para justificar ter mecanismos de suporte. No Windows 7, daremos suporte a esse cenário e muitos outros com menos serviços de início automático porque foram criados mecanismos mais abrangentes de acionamento de serviços.

Conforme observado acima, a inicialização de dispositivos e drivers também pode ter contribuição significativa. No Windows 7, nos concentramos bastante em aumentar o paralelismo da inicialização de drivers. Este paralelismo aumentado diminui a probabilidade de que alguns dispositivos/drivers mais lentos tenham impacto sobre o tempo geral de inicialização.

Em termos da leitura de arquivo a partir do disco, o Windows 7 possui melhorias na lógica e mecanismos de "pré-busca". A pré-busca foi introduzida no Windows XP. Já que os discos de hoje possuem características de desempenho diferentes, a lógica de agendamento sofreu algumas mudanças para manter o ritmo e eficiência. Estamos, por exemplo, avaliando o mecanismo de pré-busca nos dispositivos de armazenamento robustos de hoje, indo tão longe quanto questionar se é realmente necessário. No fim das contas, a métrica de análise e desempenho captada num sistema individual irá determinar dinamicamente até que ponto utilizamos o pré-busca.

Também existem experiências de diagnóstico melhoradas no Windows 7. Buscamos identificar rapidamente problemas específicos em sistemas distintos e oferecer ajuda para resolver esses problemas. Acreditamos que essa é uma boa maneira de informar os usuários quanto a alguns problemas, tais como ter aplicativos de inicialização demais ou a presença de scripts de logon extensos voltados para domínio. Como muitos usuários sabem, ter aplicativos de inicialização demais freqüentemente resulta num tempo longo de inicialização. Poucos usuários, entretanto, conhecem as implicações de ter scripts de inicialização ou logon problemáticos. No Windows XP, Vista e Windows 7 o comportamento padrão do Windows é fazer o logon do usuário até a área de trabalho sem esperar pela execução de uma inicialização de rede ou scripts potencialmente extensos. Em ambientes corporativos, entretanto, é possível que as organizações de IT alterem o padrão e configurem os sistemas dos clientes para entrar em contato com servidores através da rede. Infelizmente, ao configurar os clientes para executar scripts, os administradores de domínio tipicamente o fazem de forma simultânea e obstrutiva. O resultado é que a inicialização e logon podem levar vários minutos se existirem problemas de tempo limite de sistemas de rede ou de autenticação do servidor. Além disso, esses scripts podem executar vários programas dispendiosos que consomem recursos de CPU, disco e memória.

Além de trabalhar com recursos específicos e serviços do Windows 7, estamos compartilhando ferramentas, testes e dados com nossos parceiros. As ferramentas também estão disponíveis para entusiastas. As ferramentas que utilizamos internamente pra detectar e corrigir problemas de inicialização estão hoje disponíveis de graça aqui como parte do Kit de Ferramentas de Desempenho do Windows. Apesar de não serem adequadas para a maioria dos usuários, as ferramentas estão se mostrando muito úteis para alguns.

Um dos assuntos dos quais queremos falar futuramente, e sabemos que já se escreveu muito sobre ele e que já foi objeto de muitos comentários, é o papel que softwares adicionais além da instalação inicial do Windows têm no desempenho geral do sistema. Toda essa amplitude e profundidade de softwares para Windows significa que alguns deles não terão a alta qualidade que se espera, apesar de a grande maioria ser muito boa. A Microsoft tem que continuar a oferecer as ferramentas para os desenvolvedores escreverem softwares de alto desempenho e as ferramentas para que os usuários finais identifiquem o software em seu sistema que poderá contribuir para um desempenho abaixo das expectativas. O próprio Windows tem que continuar a melhorar as táticas defensivas que utiliza para isolar e informar o usuário final quanto a softwares que podem contribuir para desempenho insuficiente.

Outro possível assunto futuro se refere a alterações de configuração que um usuário pode fazer em seu próprio sistema. Muitas alterações recomendadas não ajudam de forma alguma. Por exemplo, descobrimos que a grande maioria das recomendações de “ajuste de registro” era falsa. Aqui está uma das minhas favoritas. Se vocês fizerem uma busca na internet por “Habilitar Superfetch no XP” encontrarão muitos resultados. Vocês podem ter certeza de que não há uma funcionalidade Superfetch no Windows XP e nenhum benefício em configurar a chave de registro como mostrado nesses sites. Há muitas recomendações semelhantes a esse mito com relação ao agendamento de CPU, gerenciamento de memória e outras alterações de configuração que não ajudam no desempenho do sistema.

A inicialização é um dos tópicos dentro do desempenho. Conforme descrito nos artigos anteriores, queremos continuar a discussão em torno desse assunto. Quais elementos vocês gostariam de discutir mais?

Michael Fortin

Windows 7 – Abordagem ao Desempenho do Sistema

Muitas pessoas fizeram comentários e mandaram email sobre o desempenho do Windows. O diálogo tem sido bem abrangente – todos querem ver uma melhoria no desempenho (obvio). Assim como muitos outros tópicos discutidos aqui, desempenho, mesmo parecendo mensurável e absoluto, também traz lá suas sutilezas. Existem muitos elementos e muitos balanços envolvidos em conseguir um desempenho que se adéqua as expectativas de todos. Sabemos que mesmo atendendo as expectativas, as pessoas vão querer sempre mais dos seus PCs com Windows (conforme esperado). Nós nos re-dedicamos a trabalhar nessa área no Windows 7 (e no IE 8). Essa foi uma grande iniciativa envolvendo todos os times de funcionalidade assim, e foi também a missão principal de um dos times de funcionalidade (equipe de Fundamentos). Nesse artigo, eu gostaria apenas de iniciar a discussão na medida em que nos aprofundamos no tópico de desempenho nos próximos artigos. Vocês podem achar relevante esse outro artigo sobre desempenho do IE8 e também o lançamento da versão Beta 2 do IE8.

Desempenho é composto de muitos elementos. Poderíamos falar sobre resposta do sistema para um chamado específico. Poderia também significar quanto de memória é “típica” ou qual processador clientes precisam. Poderíamos falar sobre o tempo preciso pra iniciar um programa. Poderia significar tempo de inicialização, ou pausa/reinicializarão. Poderia significar o monitoramento da atividade no processador, ou leituras/escritas no disco (ou a ausência de atividade no disco). Poderia significar tempo de duração da bateria em laptops. Poderia até significar algo bem mundano como espaço no disco após instalação. Todas essas são medidas de desempenho. Todas essas variáveis são acompanhadas sistematicamente ao longo do nosso projeto de desenvolvimento. Nós monitoramos desempenho através da execução de um conjunto de cenários (existem milhares deles) e nossos engenheiros de software também executam cenários específicos baseado em uma maior abrangência ou profundidade. A lista a seguir representa algumas (essa é uma lista parcial) das medidas que estamos acompanhando enquanto desenvolvemos o Windows 7:

· Uso de Memória – Quanto de memória um dado cenário aloca durante sua execução. Como vocês sabem isso é um balanço clássico entre tempo e espaço na ciência da computação e nós não estamos isentos. Observamos esse balanço bastante em memórias caches quando você pode usar mais memória (ou espaço no disco) para melhorar o desempenho ou para evitar recomputar alguma coisa.

· Utilização do Processador – Claramente, processadores modernos oferecem um poder incrível de processamento e com o advento de multi-core (núcleos de execução distintos no mesmo circuito integrado) vemos a oportunidade para um maior paralelismo do que seria possível anteriormente. Claro que esses recursos não são gratuitos então medimos a utilização do processador através de medidas comparativas também. Em geral, a meta deveria ser manter a utilização do processador baixa, visto que isso traz melhorias em cenários envolvendo múltiplos usuários assim como reduz o consumo de bateria.

· Leitura e Escrita em Disco – Apesar dos discos rígidos terem melhorado substancialmente seu desempenho, ainda precisamos fazer o que for possível parar minimizar a quantidade de leituras e escritas no disco que o Windows exige (incluindo paginação de memória, claro). Essa é uma área que recebeu uma atenção especial no Windows 7 com o advento de dispositivos de armazenagem em “estado sólido” que têm características dramaticamente diferentes.

· Inicialização, Finalização, Pausa/Reinicialização – Todas essas são áreas que dedicamos bastante atenção no Windows 7. Reconhecemos que essas áreas nunca vão ser rápidas o suficiente. Para esses tópicos a nossa colaboração com os fabricantes de PC e componentes de hardware têm um papel fundamental na garantia de que os tempos que observamos em nossos laboratórios (ou o desempenho que observamos numa “instalação limpa”) são refletidas nos PCs que se encontram à venda.

· Sistema base – Fazemos várias medições e ajustes no sistema base. Com sistema base nos referimos a utilização de recursos antes de qualquer outro software ser carregado. Esse sistema forma a “plataforma” que define o que todos os engenheiros de software podem contar e definir como requisitos de sistema para uma experiência razoável. Uma sugestão popular nessa área é tirar algo do sistema base e usá-los apenas “sob demanda”. Esse balanço é algo que sempre consideramos bastante, mas sempre temos cuidado parar evitar uma situação em que a maioria dos clientes tem que fazer uma leitura “sob demanda”, algo que poderia reduzir o desempenho em cenários comuns.

· Espaço em Disco – Apesar de não estar diretamente relacionada ao desempenho de execução, muitas pessoas consideram espaço em disco do sistema operacional como um indicativo de desempenho. Nós temos algumas metas específicas em torno dessa medida e vamos nos aprofundar nos detalhes em breve. Também vamos dedicar algum tempo explicando \Windows\WinSxS visto que esse é sempre um assunto de discussões na TechNet e MSDN! Nessa área, em vez de balanços na velocidade de execução, vemos mais uma questão de balanços de recursos que trazem conveniência, tais quais drivers de dispositivo armazenados no disco, conteúdo de assistência, componentes opcionais do Windows, e também diagnósticos e informação relacionadas ao monitoramento do sistema.

Nós temos critérios que adotamos no final de cada etapa do projeto e antes de entrarmos em beta e jamais lançamos uma versão sem que tenhamos atingido esses critérios de uma forma abrangente. Algumas vezes esses critérios são micro-benchmarks (page faults, utilização de processadores, working set, frame rates em jogos) e outras vezes são mais baseados em cenários e medem o tempo parar completar uma tarefa (tempo de relógio, número de cliques). Fazemos essas medições em uma variedade de plataformas (32 bits, 64 bits; 1, 2, 4 Gb de RAM; discos de 5400 ate 7200 rpm ou discos de “estado sólido”; uma variedade de processadores, etc.). Por causa dos balanços inerentes em algumas abordagens de arquitetura, freqüentemente incluímos código condicional dependente de qual plataforma o Windows esta rodando.

Por outro lado, desempenho deveria ser bem simples – usar menos, fazer menos, ter menos. Se você tivesse menos de tudo o desempenho deveria melhorar. No extremo isso certamente é o caso. Mas como podemos ver nos comentários, o que para uma pessoa é essencial, pra outra pessoa é desnecessário. Vemos muito isso no que alguém se referiu como “colírio parar os olhos” – recebemos inúmeros pedidos parar fazer a interface do usuário “mais divertida” com animações e gráficos (“como aqueles do concorrente”) enquanto algumas pessoas falaram “pode eliminar todos esses gráficos e voltar à interface do Windows 2000”. O Windows é bem flexível e oferece muitas formas de ajustar a experiência. Ouvimos muito nesse fórum sobre oferecer versões diferentes do Windows customizadas para públicos diferentes, enquanto também ouvimos muito sobre a necessidade de redução do numero de versões do Windows. Entretanto, existem limites no que podemos oferecer e ao mesmo tempo oferecer uma plataforma confiável que clientes e programadores podem contar, sendo robusta gerenciável para uma variedade de clientes. Mas claro que dentro de um contexto definido (em uma casa ou uma empresa rodando um conjunto definido de aplicativos) sempre será possível tirar vantagem de customização e ferramentas de gerenciamento que o Windows oferece para ajustar a experiência. A habilidade de escolha e controle do que acontece em um PC é de fundamental importância para nós continuaremos enfocando nesses atributos no Windows 7.

De longe o maior desafio em prover uma ótima experiência no PC relativa a desempenho é que clientes continuam a usar os PCs para fazer mais e mais coisas, e certamente esperam fazer coisas em um PC simplesmente adicionando mais e mais aplicativos. Enquanto é definitivamente o caso de que o Windows também adiciona funcionalidade, trabalhamos duro para adicionar funcionalidades que beneficiam o maior número de clientes. Ao mesmo tempo, o Windows 7 vai continuar a oferecer escolha e controle sobre o que acontece no Windows no que diz respeito aos programas que são oferecidos, quais handlers estão disponíveis para um tipo de arquivo ou protocolo, e oferecendo uma plataforma que torna fácil aos usuários-finais personalizar a sua experiência computacional.

Finalmente, vale a pena considerar parâmetros do mundo real versus ideais. Para que possamos desenvolver o Windows, executamos nossas comparações no laboratório de forma que possamos rastrear qual código foi alterado e qual o impacto que esse código causou. Também trabalhamos juntos com fabricantes de PC ajudando eles a avaliar os sistemas que saem de suas fabricas. Mas para o desempenho verdadeiro no mundo real, o Microsoft Customer Experience Improvement Program nos fornece (anônimo, privado, opcional) dados de como as maquinas estão realmente desempenhando. Vamos nos referir a esses dados bastante nos próximos meses na medida que formar uma base para falarmos de como as coisas estão realmente funcionando, em vez de usar outras formas menos confiáveis de informação.

No nosso próximo artigo vamos avaliar inicialização e desempenho de boot, e dado o interesse que ainda teremos mais a dizer sobre esse assunto de desempenho.

-- Steven

O “Ecossistema”

Nos emails e comentários, muitos tópicos foram levantados e freqüentemente notamos vários aspectos de uma questão serem ventilados. Um tema que emergiu foi o desejo das pessoas de escolherem o que é melhor pra cada um. Eu gostaria de explorar o tema de variedade de escolha já que essa é uma parte importante de como abordamos o desenvolvimento do Windows – escolha em todos os sentidos. Essa variedade de escolha deriva do fato de que o Windows faz parte de um ecossistema, no qual muitas pessoas estão envolvidas em fazem escolhas relativas aos tipos de computadores, configuração do sistema operacional, e aplicativos/serviços que eles criam, oferecem, ou usam. O Windows é um componente desse ecossistema, e nosso objetivo com o Windows 7 é fazer um bom trabalho em todos os aspectos relacionados ao ecossistema.

Ecossistema e variedade de escolha caminham de mãos dadas. Quando desenvolvemos o Windows temos em mente um grande número de representantes do nosso ecossistema além do Windows:

• Fabricantes de PC
• Componente de hardware
• Engenheiros de software
• Entusiastas

Cada uma dessas partes tem um papel fundamental na experiência proporcionada pelo PC e também em prover uma experiência personalizada e diferenciada, e onde empresas podem lucrar com o fornecimento de produtos e serviços únicos e diferenciados (oferecendo assim mais opções aos clientes). Para o Windows 7, nossa meta foi ser claro em relação aos nossos planos e mais consistente na execução desses planos de tal forma que cada parte do ecossistema pudesse se beneficiar ao máximo das oportunidades oferecidas ao desenvolver pro Windows.

Fabricantes de PC (OEMs) são um ponto importante de integração em vários aspectos do ecossistema. Eles compram e integram componentes e pre-instalam aplicativos. Eles trabalham com varejistas na distribuição dos PCs e assim por diante. As opções que eles oferecem em formatos dos PCs e design industrial são coisas que valorizamos extremamente como pessoas. Recentemente vivenciamos uma explosão na chegada de laptops de baixo custo e laptops que são ultrafinos. Cada um tem uma combinação única de funcionalidades e benefícios. A variedade oferecida aos clientes, embora às vezes parecer demais, permite uma riqueza sem precedentes. Para o Windows 7, nós estamos trabalhando bem próximos aos OEMs desde o começo do projeto para desenvolver uma visão compartilhada de como gostaríamos de proporcionar uma experiência excelente para nossos clientes. Juntos nós compartilhamos opiniões sobre como eles podem oferecer uma experiência diferenciada, resposta dos clientes aos programas que vem pre-instalado, e criamos parcerias na medição do desempenho de novos PCs em métricas chave como inicialização (boot) e finalização (shutdown).

Componentes de hardware incluem tudo desde a CPU até os periféricos principais de entrada e saída até componentes agregados. A variedade de dispositivos compatíveis com o Windows através do trabalho dos fabricantes de componentes de hardware independentes (IHVs) é inigualável. Desde o Windows 95 e a introdução do plug-and-play continuamos o trabalho de melhorar a experiência de adquirir novos dispositivos e fazê-los funcionar simplesmente conectando-os ao PC – uma coisa que também permite vivenciar melhorias na experiência de uso independente das versões novas do Windows. Essa é uma área na qual algumas pessoas sugerem que deveríamos suportar uma quantidade menor de dispositivos com garantia de funcionamento. Mas a própria variedade de escolha e melhorias constantes em hardware depende da habilidade dos fabricantes (IHVs) de prover aquilo que eles consideram experiências diferenciadas no Windows, freqüentemente independente da versão do Windows. O modelo de drivers de dispositivo é a tecnologia chave que a Microsoft proporciona no Windows pra fazer isso tudo funcionar. Para o Windows 7, nos comprometemos a continuar a estabilização do modelo de driver e de propagar o trabalho iniciado com o Windows Vista pro Windows 7 de uma forma fácil e transparente. Os drivers são onde os fabricantes expressam a experiência diferenciada que eles oferecem, portanto variedade de escolha e oportunidade é super importante. Acho que seria justo falar que a maioria de nós deseja uma experiência em que uma instalação “limpa” do Windows 7 deveria funcionar bem simplesmente baixando drivers do Windows Update quando necessário. Hoje, com a maioria dos PCs modernos isso realmente funciona com melhorias incríveis comparado com apenas alguns anos atrás. Assim como com os fabricantes de PC, temos também trabalhado com os fabricantes de componente por um bom tempo. No WinHEC teremos a oportunidade de mostrar os avanços do Windows 7 no que diz respeito a dispositivos e o ecossistema de hardware.

Engenheiros de Software escrevem os programas para o Windows. Assim como no ecossistema de hardware, o ecossistema de software suporta uma variedade de pessoas desenvolvendo na plataforma Windows. Os engenheiros de software sempre ocupam um lugar especial no coração da Microsoft, visto que nossas raízes são na área de linguagens de programação. Cada versão do Windows traz novas APIs e serviços de sistema para utilização por programadores para construir o que quer que eles queiram construir. Existem dois desafios que enfrentamos ao desenvolver Windows 7. Primeiro, gostaríamos de ter certeza que programas que funcionam em Windows Vista também funcionarão no Windows 7. Esse é um compromisso que estabelecemos desde o inicio do projeto. Como todos sabem, esse é talvez o componente mais crítico no desenvolvimento de um sistema operacional em termos de compatibilidade. Algumas vezes não conseguimos manter a compatibilidade então a cada versão nós testamos e verificamos uma variedade de aplicativos antes do lançamento. Testes de Beta nos ajudam certamente, mas não tem o rigor sistemático que buscamos. A telemetria que mostra o quanto melhoramos a cada versão do Windows é um aspecto importante. Algumas vezes quando nós não somos compatíveis, essa telemetria nos ajuda a corrigir problemas mesmo depois do lançamento. Se você vivenciou uma falha no aplicativo e estava conectado à internet, existe uma boa chance de você ter recebido uma mensagem sugerindo que atualizações estão disponíveis. Sabemos que temos que fechar o ciclo satisfatoriamente. Também precisamos aprimorar as ferramentas e práticas que programadores em Windows têm disponível para evitar essas situações – na outra ponta de tudo isso tem um cliente e deixá-lo confuso entre a Microsoft e o desenvolvedor do programa não é a melhor solução.

Nosso segundo desafio é prover novas APIs para programadores que os ajudam a prover novos recursos em seus aplicativos, e ao mesmo tempo oferecer valor suficiente de forma a justificar o investimento no aprendizado e uso dessas APIs. Internamente, sempre falamos sobre “grandes” avanços na interface gráfica em geral (tais como o uso da área de trabalho ou a habilidade de imprimir sem ser necessário desenvolver um modelo de driver especifica para o aplicativo). Hoje em dia funcionalidades como acesso a rede e computação gráfica são vitais em desenvolvimento de aplicativos. Discutimos anteriormente sobre novos recursos tais quais as interfaces de toque no Windows 7. Fomos também muito claros sobre a visão de que 64-bits é o lugar correto para programadores focarem suas energias, visto que a transição está a caminho e uma área que estamos claramente focados.

Entusiastas são facilitadores chave para o ecossistema, e que quase sempre são os que trabalham pelo simples prazer de contribuir. Como leitor desse blog existe uma grande chance que você representa essa parte do nosso ecossistema – mesmo trabalhando na indústria, somos também “fãs’ da indústria. Existem muitos aspectos em uma versão do Windows que precisão animar os entusiastas. Por exemplo, muitos de nós somos a primeira linha de configuração e integração para familiares, amigos, e vizinhos. Eu sei que dediquei parte do meu sábado instalando uma rede sem fio para uma professora amiga minha e tenho certeza que muitos de vocês fazem o mesmo. Entusiastas são também os mais radicais em querer opções e controles em seus PCs. São as revistas e sites de entusiastas que começaram a avaliar novos PCs baseados nos aplicativos pre-instalados e quão limpas são essas instalações. São os entusiastas que exploram os limites de novos recursos tais quais desempenhos gráficos em jogos eletrônicos. São os entusiastas que estão adotando Windows em 64 bits e encorajando a Microsoft a garantir que o ecossistema estará pronto para a versão do Windows 7 em 64 bits (obviamente estamos fazendo isso). Eu penso em entusiastas como a linha mestra que une todas as partes do ecossistema, participando em cada fase e em cada segmento. Esse blog é uma chance de compartilhar com entusiastas os detalhes sobre todas as decisões que precisamos tomar ao desenvolver o Windows 7.

Existem muitos outros participantes no ecossistema que são igualmente importantes como pontos de integração. Os integradores de sistema e revendedores fornecem PCs, aplicativos, e serviços para pequenas e médias empresas ao redor do mundo. Muitos leitores desse blog, com base nos emails que recebi, representam essa parte do ecossistema. Em muitos países os varejistas também atuam como pontos de integração para o consumidor final. Para grandes empresas os profissionais de TI necessitam o máximo de personalização e gestão de grande número de PCs. Suas necessidades são demandantes e variam bastante de empresa pra empresa.

Algumas pessoas mencionaram que o ecossistema não é a melhor abordagem e que deveríamos reduzir a superfície do Windows e suportar menos dispositivos, menos PCs, menos aplicativos, e menos bagagem do passado do Windows. Julgando pela diversidade de pontos de vista nesse assunto acredito que as pessoas necessitam de muita variedade de opções (por exemplo, em termos de DPI e tamanho do monitor). Alguns podem argumentar que uma superfície mais limitada facilita a engenharia de soluções (por definição isso é verdade), mas na verdade essa visão resultaria numa redução constante de opções disponíveis a clientes. A realidade é que a arte da engenharia é resolver problemas com as limitações impostas e que podemos encarar essas limitações como ativos, assim como encaramos a abrangência de dispositivos, aplicativos, e “historia” do Windows. O ecossistema do PC depende da oportunidade de muitas pessoas tentarem muitas idéias, incluindo aquelas que possam parecer um pouco malucas a princípio, mas que se tornam populares mais tarde. Com o Windows 7, estamos renovando nosso esforço em preparar o ecossistema e ao mesmo tempo alavancando o trabalho de todos no Windows Vista.

O ecossistema do Windows é bem significativo tanto na profundidade como na abrangência das partes envolvidas. Eu achei que para o propósito do diálogo nesse blog seria importante enfatizar isso logo de início. Sempre existe algum impacto em balancear as necessidades de cada aspecto do ecossistema. Otimizando completamente ao longo de uma única dimensão algumas vezes parece certo no curto prazo, mas no longo prazo é uma prática arriscada uma vez que os benefícios de uma plataforma estável que permite diferenciação é algo que parece beneficiar todos.

Com o Windows 7 estamos nos comprometendo de início em fazer um ótimo trabalho como participantes do ecossistema de PCs.

Esse artigo reflete sua visão do ecossistema? Como poderíamos descrever melhor os envolvidos em fazer a experiência em PCs ser fantástica pra todos?

-- Steven