Internet Explorer 9: Acelere a compatibilidade de aplicativos empresariais
Migrando do Internet Explorer 6 para um navegador moderno pode ser mais rápido, mais barato e fácil do que imagina — se você souber os truques certos.
Chris Jackson
Ninguém está feliz por ainda estar em um navegador antigo como o Internet Explorer 6. As pessoas a cabeça e reclamam sobre os novos recursos não têm, os aplicativos que não funcionam mais, e o desempenho insuficiente. Ainda, há, ainda executarem o Internet Explorer 6. Por quê? It’s simple: they’re afraid that their stuff will break.
Você não que ser quem trazida para a empresa para um dia por causa de um aplicativo de missão crítico quebrado. Portanto, você permanece, paralyzed por medo e ambigüidade. O processo de migração para 9 do Internet Explorer pode não estar livres de problemas, mas se você aproveitar alguns truques, você honestamente torna mais rápido, mais barato e fácil.
Superar a ambigüidade
Antes de começar seu projeto de compatibilidade de aplicativos, você poderá não se sentir como se você tiver os dados que necessários para medir com precisão os riscos envolvidos. Afinal, você pode listar realmente todos os sites que todos em sua organização nunca visitou? Quais são os riscos true?
Na versão mais recente do que o Microsoft Assessment and Planning (MAP) Toolkit, há alguns recursos de inventário do Internet Explorer. Ele faz o inventário não somente os navegadores instalados em um computador (e qual navegador está definido como padrão), mas também quais complementos estão instalados para o Internet Explorer (como, por exemplo, ActiveX controles ou objetos auxiliares do navegador). Isso pode ajudá-lo a entender o código em execução dentro de navegadores dos usuários.
Você não pode obter uma lista completa de todos os sites visitados por causa das razões técnicas, legais e de privacidade. Ausente, você poderia fazer coisas como consultar os servidores proxy para determinar quais sites são acessados através delas. No entanto, embora você possa fazer uma grande lista de URLs, se você experimentar o disco rígido suficiente, é quase nunca uma boa idéia.
Pense nisso. Quantas vezes em um dia comum você visita sites da Web que não têm impacto sobre o seu trabalho? Quantos sites você faz uso, se eles sumiu amanhã, você teria apenas aonde encontrar outros? Se você desempenhou um inventário dos sites da Web eu pessoalmente visitado e, em seguida, rigorosamente testado-los, pelo menos 95% desse esforço acabaria sendo desperdício de tempo. É o medo de localização não 5% dos sites que os usuários perderia que as pessoas queiram um exaustiva Recenseamento dos sites de drives.
Identificar os aplicativos
Aqui está outra abordagem: descobrir quais aplicativos absolutamente, positivamente tem que trabalhar no primeiro dia. Esses são os aplicativos que você precisa testar proativamente antes de implantar uma única estação de 9 do Internet Explorer. Depois que você desmarcou os aplicativos de missão crítica, você pode começar a implantar.
Inicie a implantação de algumas estações. Ter suficiente help desk de suporte conhecimentos sobre compatibilidade de aplicativos da Web para gerenciar o volume de entrada adicional por causa do novo navegador. Ter um plano para problemas de endereçamento e uma barreira para emergências.
Se o suporte técnico fica sobrecarregado, lenta a implantação. Se elas são OK e você ainda tem a capacidade, você pode acelerar o processo. É melhor se você puder fazer a implantação-consentimento do usuário. Usuários pedindo novo navegador será mais forgiving se algo der errado.
A vantagem desse plano é que você não precisa testar tudo. Normalmente, os usuários só vai reportar um problema se ele é um problema de bloqueio para eles. Caso contrário, eles irão apenas sobre seus negócios. Você acaba gastar menos tempo testando aplicativos que os usuários não se preocupa realmente. Você gasta menos tempo fazendo testes proativos. Os usuários podem determinar se um aplicativo realmente funciona ou não.
Portanto, seu teste proativo de compatibilidade de aplicativos não realmente determine a compatibilidade? Ele é um conceito incomuns. Considere o que significa ser compatível. Isso significa que você não ter nenhum bug em uma plataforma que o impedirão de trabalho. Agora, todos nós sabemos que você não pode chegar ao ponto em que um produto tem zero bugs. Basta provar que nenhum deles impedi-lo de obter o trabalho feito. Sua comunidade de usuários é produtiva, desde que você está em bom estado.
Essa combinação de testes proativas e reativas — uma abordagem que combina o gerenciamento de riscos sensato, capacitação do usuário e agilidade de plataforma — é puro ouro de compatibilidade de aplicativos. Essa abordagem pode superar inércia baseada em ambigüidade e poupa tempo e dinheiro.
Ajustar o ambiente
Quando o projeto de migração for iniciado, é hora de seu ambiente de navegador ajustado para cima, para garantir que mais aplicativos funcionem desde o início. Ao falar sobre versões modernas do Internet Explorer, que suporta os mais recentes padrões da Web, muitos acha que eles têm que atualizar todos os seus aplicativos como parte da migração. Enquanto que certamente seja um objetivo nobre, também é mais lento e muito mais caro.
9 Do Internet Explorer fornece uma infra-estrutura de compatibilidade sofisticados e gerenciável que lhe permite optar por manter tudo funcionando como padrão e então optar pelo novos padrões da Web em uma base por aplicativo. Então, como você ajustes para compatibilidade máxima? Tudo começa com zoneamento adequado.
Alguns aplicativos internos land na zona da Internet, porque elas estão usando nomes de domínio totalmente qualificado ou porque elas estão usando endereços IP para alguns aplicativos. A zona da Internet é mais restritiva e assim é muito menos compatível. Por exemplo, SharePoint não é tão bom quando zoneado incorretamente. Todos os tipos de recursos simplesmente não funcionam.
O outro problema de zoneamento é colocar aplicativos internos em zona de Sites confiáveis. No Internet Explorer 6, Sites confiáveis foi realmente a zona mais confiável. Ele realmente você deu mais energia. No Internet Explorer 9, a zona mais confiável não é confiável Sites; é da Intranet Local. Assim, você realmente está dando potência. Além disso, usando as diretivas padrão você estiver também fazendo a autenticação integrada.
Por que é Intranet Local agora mais confiável? Previously, you had two different buckets for internal applications: trusted and really trusted. Com que freqüência você precisa fazer uma distinção tal? Não que muitas vezes, quando houver uma diretiva sensato padrão para a zona Intranet Local. Além disso, ele não deixa um slot para parceiros confiáveis. Se você tiver um parceiro fornecendo correio eletrônico, colaboração e assim por diante, eles são mais confiáveis do que a Internet em geral.
Depois que você tiver aplicativos zoneados corretamente, você também land na política padrão onde a zona da Intranet Local permite a exibição de compatibilidade por padrão. Isso torna os aplicativos da Web existentes mais compatível, simplesmente em virtude de pouso na zona com o modelo de segurança mais permissivo.
Modos de compatibilidade
Isso, obviamente, nos leva ao nosso próximo tópico importante: os modos de compatibilidade e quando aproveitá-las. Este é um aspecto freqüentemente incompreendido do Internet Explorer 9. Muito dessa complexidade estiver oculto por trás de um botão aparentemente simple com uma imagem de uma página interrompida.
Tenha em mente como passar pelo processo que o Internet Explorer 9 realmente contém que quatro separar os mecanismos de processamento. Que tem quatro conjuntos de regras para layout HTML, scripts e assim por diante. No Internet Explorer 9, esses modos de renderização são:
- Sutilezas/Internet Explorer 5.5
- Padrões do Internet Explorer 7
- Padrões do Internet Explorer 8
- Padrões do Internet Explorer 9
Isso não é novidade. Even Internet Explorer 6 had two different modes: Quirks and Internet Explorer 6 Standards. Você obteria sutilezas até que o desenvolvedor consentido especificamente para padrões usando um elemento DOCTYPE na sua marcação. Internet Explorer 7 continuou a dicotomia, evoluindo e melhorando os padrões, deixando sutilezas no. Internet Explorer 8 mantidos sutilezas e Internet Explorer 7 e adicionado o Internet Explorer 8. Internet Explorer 9 é seguir essa tendência.
Portanto, você tem quatro mecanismos de renderização atrás de um único botão. Como ir e para trás entre eles? Exibição de compatibilidade processará uma página da Web que contém um DOCTYPE no modo de padrões do Internet Explorer 7. Ele processará uma página sem um no modo queres.
Se você não estiver usando o modo de exibição de compatibilidade, em seguida, uma página da Web que contém um DOCTYPE será processada no modo de padrões do Internet Explorer 9. Uma página sem um será processada no modo queres. Portanto, uma página da Web em execução no modo queres não alterará se você pressiona o botão do modo de exibição de compatibilidade. Isso altera também a versão do navegador reportado no servidor Web.
Não é uma solução extremamente amigável para instruir os usuários, pressione um botão para que uma página da Web funcionem. Agora há suporte de diretiva de grupo para o modo de exibição de compatibilidade, especificamente para tornar o padrão para a Intranet Local: modelos administrativos | Componentes do Windows | Internet Explorer | Exibição de compatibilidade | Ative o modo de padrões do Internet Explorer para Intranet Local.
Essa é uma dessas políticas duplamente negativa. Você deve desabilitar o modo padrão"" para a Intranet Local para habilitar o modo de exibição de compatibilidade. O padrão é desativado e você deverá mantê-lo dessa maneira. Isso não significa que você deseja que continue escrevendo um padrão de 5 anos. Isso significa que você já escreveu para um padrão mais antigo de coisas continuarão a funcionar. Você pode, claro, opte pelo em um determinado aplicativo Web usando um padrão mais moderno, mas você não pode usar os padrões mais recentes para nada até obter um navegador moderno implantado.
Naturalmente, há também uma diretiva de grupo para manter os aplicativos de Web de parceiros externos executando: modelos administrativos | Componentes do Windows | Internet Explorer | Exibição de compatibilidade | Use sites da lista de diretivas do Internet Explorer 7.
Se você adicionar sites específicos para esta diretiva (utiliza nomes de domínio de nível superior ou TLDNs), eles vai ser consentidos para exibição de compatibilidade e podem funcionar melhor. Exibição de compatibilidade não corrige tudo. Proveniente do Internet Explorer 6, há um motivo específico por que nem sempre ele funciona. Internet Explorer 6 não lê o DOCTYPE a menos que seja a primeira linha da marcação em sua página. Portanto, se você tiver uma página que começa assim:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
Que é um prólogo comuns para uma página XHTML: um dialeto do HTML que estava popular há alguns anos. Internet Explorer 6 irá processar qualquer XHTML que começa assim no modo queres, porque o DOCTYPE não é a primeira linha. Internet Explorer 7 fixa esse bug, então, o Internet Explorer 7 ou posterior processará no modo de padrões. Porque as regras para o layout foi alterado entre sutilezas e até mesmo padrões do Internet Explorer 6, isso pode ser um acontecimento bonito.
Para muitos, é a promoção de sites em sutilezas padrões que faz com que elas danifiquem no droves. Mais de 80% dos aplicativos foram divididos por essa alteração de um. Ele é precisamente devido essa situação e sua freqüência alarmante que adicionamos uma nova diretiva de grupo para o Internet Explorer 9 (também disponível para o Internet Explorer 8 se você aplicar o hotfix): modelos administrativos | Componentes do Windows | Internet Explorer | Exibição de compatibilidade | Use lista de diretiva de modo queres sites.
Isso lhe permite optar sutilezas de um determinado site que pode ser afetado pela Microsoft para corrigir esse bug. Isso não dá a você total controle, mas ele oferece uma maneira simples, baseada em políticas para começar.
Para obter controle total, você deve aproveitar X-UA-Compatible, onde você pode escolher explicitamente precisamente qual modo de processamento desejada. Você pode obter os detalhes completos da página Biblioteca MSDN, "Definindo compatibilidade de documentos," mas em resumo, você deve incluir tanto um cabeçalho:
X-UA-Compatible: IE=5
Ou, você incluir uma marca meta:
<meta http-equiv="X-UA-Compatible" content="IE=5"> <!-- Quirks Mode -->
<meta http-equiv="X-UA-Compatible" content="IE=7"> <!-- IE7 Standards -->
<meta http-equiv="X-UA-Compatible" content="IE=8"> <!-- IE8 Standards -->
<meta http-equiv="X-UA-Compatible" content="IE=9"> <!-- IE9 Standards -->
<meta http-equiv="X-UA-Compatible" content="IE=edge"> <!-- The latest standards - never use in production! -->
Você vai querer entender a infra-estrutura de compatibilidade e todos os modos ela pode ser configurado. Por exemplo, se você deixar a configuração padrão para Intranet Local, é usar o modo de compatibilidade. Então, vamos dizer você implementar um aplicativo HTML5. Se você não fizer nada, vai para o padrão para o modo de compatibilidade — o mecanismo do Internet Explorer 7.
Internet Explorer 7 não oferece suporte a HTML5, para que seu aplicativo não funcionará. Nem tudo está perdido, porém. Você pode adicionar um cabeçalho para o site e configurá-lo para executar no modo de 9 do Internet Explorer, ou você pode adicionar marcas meta para páginas que exigem o HTML5. Basta você anuladas os padrões e tem um modo de renderização mais moderno.
É aconselhável adicionar cabeçalhos de X-UA-Compatible ou marcas meta para qualquer aplicativo da Web que você toca. Você também deve precisar dele para novos aplicativos Web. Dessa forma, você pode manter gradualmente o suporte de padrões no futuro.
As regras de precedência também suportam essa noção. Você pode sobrepor os padrões de diretiva de grupo com o cabeçalho X-UA-Compatible e sobrepor o cabeçalho com uma marca meta de X-UA-Compatible. Em qualquer nível de granularidade que você escolher, você está no controle total do seu modo de renderização. É necessário que passar para cima e assumir que o controle se você quiser manter avançando. Portanto, certifique-se de etiquetagem de seus sites e definir os padrões para novos aplicativos.
Configurações de segurança
A próxima etapa no seu ambiente de ajuste está considerando se os recursos de segurança são significativas seus aplicativos. Algumas configurações que normalmente causam problemas incluem:
- O conteúdo é misto: conteúdo de Sites que misturar e com SSL com conteúdo não criptografado. Algumas organizações acham que isso faz com que avisos excessivos e interrupções do usuário com um grande número de sites.
- Avisos de certificado: muitas empresas não têm uma implementação de infra-estrutura de chave pública (PKI), mas prefira a segurança do SSL. Eles simplesmente pegar emprestado as chaves de um servidor e usá-los em outro.
- Proteção de execução de dados: isso pode ser uma das tecnologias atenuação de ameaças mais eficientes disponíveis. No entanto, ainda existem alguns controles de ActiveX que são incompatíveis com esse poderoso recurso de segurança.
Isso não constitui uma lista exaustiva. Você realmente não é possível ajustar o seu ambiente para esses fatores com antecedência. Esse será um processo iterativo. Se você encontrar um recurso que divide um aplicativo, anote-lo. Ele pode fazer sentido para desativá-lo por enquanto e desenvolver um plano para corrigi-lo mais tarde.
Você também deve ser cuidadoso em relação a compensação. Se você permanecer com o Internet Explorer 6, em seguida, você obterá zero por cento dos recursos de segurança adicionados desde então. Naturalmente, em vez disso, você teria que 100 por cento dos novos recursos de segurança. Se os aplicativos críticos não funcionam com tudo ativado, porém, que não é uma opção que você precisa fazer.
Você pode escolher qualquer 99 por cento dos recursos de segurança no Internet Explorer 9 (com um recurso ou dois desligado por enquanto) ou zero por cento dos recursos de segurança no Internet Explorer 9, recusando-se reduzir a postura de segurança. Também, que bloqueia a implantação. Você precisa equilibrar essas considerações.
Mente seu Middleware
Outro aspecto importante da migração para o Internet Explorer 9 é garantir que você compreenda o impacto de middleware. É especialmente importante ter a versão mais recente do Java instalada. São de versões mais antigas do Java incompatível com o Internet Explorer 9.
Muitas organizações optam por padronizar em um determinado nível de versão e atualização para Java. Basicamente, isso trave no lugar de um nível de patch específico para Java e recusa todos os novos patches de segurança. O de Centro de Proteção contra Malware da Microsoft foi avisado sobre a explorações de crescimento do número de Java, portanto, essa é uma abordagem imprudente.
Procurar causas raízes
Depois que seu ambiente é ajustado e você está divulgando assentos e iniciando obter comentários, você está vinculado a ter poucos escalonamentos. Here comes the hard part: figuring out what to do about the Web applications that are breaking.
Um aplicativo da Web geralmente é composto de três partes diferentes que são executados no navegador: HTML (normalmente gerado por uma ferramenta), o CSS (normalmente gerado por um designer) e o script (normalmente gerado por um desenvolvedor). Não há uma pessoa sabe freqüentemente minuciosamente cada uma dessas tecnologias. É difícil saber até mesmo uma delas cuidadosamente.
Ao solucionar problemas de compatibilidade de aplicativos da Web, siga uma abordagem iterativa. Inventar um motivo por que ele pode ser interrompida e encontre uma ferramenta que pode ajudá-lo a determinar se ou não está bem mais rápido possível. Se você se concentrar seu raciocínio, você pode orientar sua forma de causa muito mais rapidamente.
Às vezes, você precisará reescrever. A maioria dos problemas são facilmente corrigível problemas, como, por exemplo, verificações de versão. Por exemplo, um aplicativo pode estar fazendo uma verificação de versão explícita para o mecanismo de script, como isso (representado no pseudocódigo):
Se (majorVersion < 5 ou minorVersion < 5), falhar
Execute essa lógica pela sua cabeça. Versão 5.5 funciona bem. Portanto, seria 5.6, mas 6.0 falhará, pois 0 (a versão secundária) não é menor que cinco? Você pode corrigir isso alterando essa linha de código. Geralmente, a correção é mais fácil do que você acha que, portanto, verifique se você unidade para uma conclusão por que algo está quebrando, em vez de supondo que tudo o que precisa ser refeita.
Ter um plano de Backup
Por último, mas não menos importante, você vai querer ter um plano de backup. Quando você tiver um aplicativo que exige suporte, mas você ainda não suporta 9 do Internet Explorer, você não poderá executá-lo. É o plano de backup para manter todos os usuários no Internet Explorer 6, ou você utilizará a virtualização para mover os usuários sobre anteriormente? Examine o white paper, "soluções para virtualização Internet Explorer," e desenvolver um plano que oferece a você uma Hachura escape se algo der errado.
Em média, a organização típica, mudança do Internet Explorer 6 para Internet Explorer 9 localiza 25 por cento de seus aplicativos não funcionam prontos para uso no Internet Explorer 9. Após o ajuste de cuidado, esse número de descartes para uma média de menos de 5%.
Os clientes mudando do Internet Explorer 7 para 9 do Internet Explorer normalmente têm 4 a 5% de seus aplicativos não trabalhando de imediato, com o número após o ajuste de soltar em menos de 2 por cento. Para empresas que já usam o Internet Explorer 8, quase tudo funciona fora da caixa.
Espero que essas dicas, coletadas de metade de uma década de ajudar as organizações avança a partir do Internet Explorer 6, irá ajudá-lo a aproveitar os benefícios de um navegador moderno. Junte um plano de projeto com base no risco que incorpora o envolvimento do usuário, aproveita os recursos de gerenciabilidade e compatibilidade do navegador existente, menos dispendiosas baseada em código correções possíveis de buscas e tem uma trava de escape para quando algo dá errado. Centenas de empresas removeu o enfraquecido que ligá-los a navegadores herdados. Você pode fazer o mesmo.
.jpg)
Chris Jacksoné "The App Compat Guy" na Microsoft. Ele é um consultor principal e o líder mundial de compatibilidade de aplicativos corporativos. Ele é palestrante assíduo em IT e conferências de desenvolvedores e funciona com clientes e parceiros em todo o mundo. A missão dele é "Restaurando agilidade de tecnologia, removendo o enfraquecido do software legado". Leitura mais de Jackson em seu blog (appcompatguy.com) e no Twitter no twitter.com/appcompatguy.