domingo, 31 de maio de 2009

Tabelas vs Div’s e Css – Em busca do layout perfeito



No início da Internet as páginas eram constituídas, praticamente, apenas por uma amalgama de texto e imagens. A maior parte dessas páginas tinha como objectivo a troca de informação nos mundos académico, militar e de investigação científica, não necessitando de grandes cuidados visuais.
Mas, principalmente com o aparecimento das primeiras possibilidades de negócio online, tornou-se necessário arranjar uma forma de conseguir apresentar a informação de uma forma mais ordenada e agradável ao visitante.

A primeira forma encontrada para este propósito foi a nossa conhecida tabela, que permite apresentar dados de forma tabular e, ao aparecer a propriedade border = 0, tornou-se possível organizar a informação sem que o visitante visse a inestética estrutura da tabela.
Contudo, embora ainda hoje em dia as tabelas sejam de grande utilidade, é certo que trazem também algumas complicações a quem desenvolve qualquer tipo de aplicação web. Os principais problemas ao utilizar tabelas para construir o layout de um site resumem-se, em termos gerais, aos seguintes pontos:
  • mistura dos dados de apresentação (ou seja, a estrutura da tabela, tamanhos, cores, etc) com o conteúdo (texto, imagens, etc), o que leva ao aumento desnecessário do tamanho do ficheiro que representa a página;

  • a largura de banda não é grátis, tanto para o visitante como para o dono do site, e visto que os ficheiros têm um tamanho maior devido aos dados de apresentação, verifica-se um aumento na largura de banda consumida sempre que um visitante visualiza uma página;

  • o acesso a utilizadores de PDA’s e telemóveis torna-se mais complicado devido à necessidade de maior largura de banda e aos browsers existentes para esses dispositivos;

  • embora seja possível definir informação sobre o conteúdo nos cabeçalhos das tabelas, a acessibilidade para utilizadores com dificuldades torna-se complicada caso existam várias tabelas dentro de outras tabelas;

  • torna-se mais complicado de manter constante o aspecto visual em todo o site;

  • o redesign de um site torna-se muito mais complicado e moroso.

Mesmo com tantos pontos negativos as tabelas continuam a ser largamente usadas por toda a Internet, porquê?
Bem, principalmente devido a dois pontos:
  • são simples de usar, o que serve de apoio para muitos utilizadores que pretendem criar uma página web e não têm conhecimentos aprofundados sobre o assunto;

  • devido aos diferentes métodos de renderização ainda existentes entre os diversos browsers, o que pode provocar alguma inconsistência visual num site.

Afinal se utilizar tabelas para criar o layout de um site é assim tão mau, qual é a solução para esse problema?


A solução para o problema passa pela utilização de Cascading Style Sheets (CSS) em conjunto com div’s.

Nota:
CSS representa todas as regras de apresentação que são utilizadas numa página ou site, onde é possível definir desde a cor da letra até à largura de um div.
div representa uma divisão numa página, podendo esta ser apresentada de diversas formas na página: ocupar um bloco que a toda a largura da página, flutuar à esquerda, flutuar à direita, ocupar apenas o espaço necessário para apresentar a informação contida, etc.

Como os browsers modernos são muito melhores a fazer a renderização de páginas web do que os existentes na altura em que se começaram a utilizar tabelas, podemos recorrer a esta solução tendo em especial atenção a criação de um ficheiro CSS geral para todo o site e a atribuição de nomes (identificadores) sugestivos para os diferentes div’s que irão fornecer o pretendido aspecto "tabular” da página.

A solução CSS + div dá-nos então alguns aspectos superiores à solução com tabelas:
  • devido à separação dos dados de apresentação (presentes no ficheiro CSS) do conteúdo da página, a largura de banda consumida será menor, sendo apenas necessário carregar os dados de apresentação na primeira visualização de uma página do site. Como esses dados serão utilizados ao longo de todo o site, e devido ao sistema de cache do browser, não será necessário fazer o download de todos os dados de apresentação sempre que se visualiza uma nova página;

  • o ficheiro CSS único oferece-nos a possibilidade de realizar um redesign de forma muito mais rápida e automaticamente extensível a todas as zonas do site que utilizem as regras alteradas, não sendo necessário editar página a página;

  • o aspecto visual em todo o site torna-se constante, desde que os dados de apresentação presentes no ficheiro CSS sejam utilizados correctamente;

  • os nomes sugestivos dos div’s oferecem-nos não só a possibilidade de criar uma regra de estilo específica para esse div, como também uma maior facilidade em perceber que dados serão apresentados no seu interior, melhorando assim a acessibilidade do site para utilizadores com dificuldades;

  • embora nem todos os browsers apresentem os div’s, da mesma maneira, é possível minimizar as inconsistências visuais através da utilização de um div extra que realiza um "reset" às formatações no sítio onde este se encontra.

Parece-me bem, mas soa a algo complicado de fazer...


Parece complicado, mas na realidade não o é. Após algumas edições este processo torna-se algo natural de fazer.
É natural também que existam ainda algumas situações em que seja necessário recorrer a uma tabela para apresentar alguns dados, mas estas deverão ser usadas apenas para o seu propósito - apresentação de dados de maneira tabular - e não para criação de layouts completos.
Caso existam algumas dúvidas sobre como começar, não há nada como uma boa pesquisa na Internet para as desfazer. Existem vários sites que referem métodos para se construir um layout com um aspecto sólido utilizando apenas CSS e div’s, merecendo o artigo de Matthew James Taylor um destaque especial.

terça-feira, 26 de maio de 2009

Application Compatibility Toolkit 5.5



Esta aplicação tem como finalidade ajudar a perceber quais as possíveis incompatibilidades que possam ocorrer aquando a instalação de um novo sistema operativo, ou uma actualização do mesmo ou até mesmo na instalação de uma nova actualização do Internet Explorer. É produzido um relatório com as anomalias encontradas que permite, após devida análise, conceber um plano com possíveis soluções para as resolver e posteriormente criar pacotes de mitigação que, ao serem aplicados e quando possível, resolvem os problemas encontrados.
Este processo é executado por três fases utilizando a arquitectura resultante da instalação do ACT:

Fase 1 – Inventariar informação

Antes da análise dos potenciais problemas de compatibilidade, primeiro tem de ser coleccionar a informação de toda a organização. Para tal utiliza-se a ferramenta Application Compatibility Manager (ACM) que permite que se configure, coleccione, organize e analise a compatibilidade dos dados. A forma de comunicação de toda a organização para recolha e armazenamento da informação relevante a problemas de compatibilidade é uma pasta partilhada que funciona como um registo (Log Processing Service – LPS), colocando depois esta informação numa base de dados, criada no processo de configuração do ACM, especialmente para esta aplicação. É a esta base de dados que o ACM acede e que tem toda a informação de toda a organização.


Fase 2 – Analisar problemas

Depois de inventariados os dados da organização é altura de analisá-los. Isto inclui categorizá-los e organizá-los de forma a proporcionar uma leitura mais fácil de toda a informação que está disponibilizada no ACM após colecção dos dados. Além desta opção, existe também hipótese de utilização de três ferramentas mais específicas para pesquisa de incompatibilidades:

Internet Explorer Compatibility Test Tool (IECT) – Permite que se coleccione as incompatibilidades em Web Sites e Aplicações Web e mostra os resultados em tempo real no Internet Explorer 7.

Setup Analysis Tool (SAT) – Permite que se detecte problemas que possam ocorrer durante uma instalação e configuração de uma aplicação.

Standard User Analyzer (SUA) – Permite que se detecte problemas que possam ocorrer em aplicações a funcionar em ambientes de Standard User, ou seja, quando os utilizadores comuns não são administradores.

Fase 3 – Testes e Mitigações

Por último, depois de testados todos os problemas encontrados, existe a possibilidade de se criarem pacotes de mitigação que posteriormente serão instalados para resolução das incompatibilidades. Para tal, utilizam-se as opções que existem em cada ferramenta de análise (IECT, SAT ou SUA) ou utiliza-se o Compatibility Administrator que nos dá a possibilidade de criar um pacote de mitigação personalizado, escolhendo que tipo de problema queremos resolver e como.

Ex. Se houver uma aplicação que não funcione devidamente se o utilizador não for administrador podemos criar um pacote de mitigação que aplique uma regra de que sejam elevadas as permissões deste utilizador naquela aplicação.



This application helps you to understand which could be your compatibility issues during an installation of a new operating system, an operating system update, or even an Internet Explorer update. It creates a report with the issues found and then, after analyze it, design a plan with possible solutions to posteriorly create mitigation packages to fix this compatibility issues.

There are three steps to execute this process using the resulting architecture from the ACT installation:

Phase 1 – Collecting Data

Before analyse potencialy compatibility problems, first collect your organization's inventory and the associated compatibility issues. For that, use the tool Application Compatibility Manager (ACM) that enables you to configure, to collect, and to analyze your data so you can fix any issues. The way that all organization communicates and share information about compatibility data is a shared folder that works like a log file (Log Processing Service – LPS), placing then this information inside a database, created during the ACM’s configuration process exclusively for this application. That is the database that ACM’s access in order to have all information about all organization.

Phase 2 – Analyzing Issues

After collecting your inventory and associated compatibility data, you can organize and analyze your issues. Besides this option, you can also use three tools more specific to search for incompatibilities:

Internet Explorer Compatibility Test Tool (IECT) – Enables you to collect, in real-time, the potential Web site and Web application issues that might occur due to running Web sites and Web applications in Internet Explorer 7

Setup Analysis Tool (SAT) – Enables you to detect problems that might occur during an application’s installation and configuration.

Standard User Analyzer (SUA) – Enables you to detect problems that might occur in applications running on standard user environments, i.e., when the common user it’s not an administrator.

Phase 3 – Testing and Mitigating Issues

After analyzing your compatibility issue reports you can create mitigation packages to fix the issues. For that you can use Compatibility Administrator or the other tools, provided with ACT, including the IECT, the SAT, and the SUA tool, to determine additional issues and possible mitigation strategies.

Ex. If there is an application that doesn’t work correctly because the user must be an administrator you can create a mitigation package that applies a rule that elevates permission to this user in that application.