Como aumentar a portabilidade nos computadores pessoais

How to Improve Portability Across Personal Computers

Autor original: Hadrien Grasland

Publicado originalmente no: osnews.com

Tradução: Roberto Bechtlufft

Hoje em dia, smartphones, tablets, desktops e laptops são todos irmãos. Todo usam os mesmos paradigmas de interface de usuário, e seguem a mesma ideia de serem máquinas programáveis e flexíveis à disposição de todos. Só o hardware e o formato físico é que diferenciam uma plataforma da outra. Diante disso, será que ainda faz sentido tratar esses dispositivos em separado na hora de desenvolver software? Não seria muito melhor considerar todos como variações de um mesmo conceito, e lançar uma plataforma unificada de software que rodasse em todos eles? Neste artigo, vou descrever o que já foi feito nesse sentido e o que ainda falta fazer.

Sistemas operacionais para vários computadores pessoais

O primeiro passo nessa direção seria criar um sistema operacional que funcionasse bem em todas as plataformas. Os principais participantes do mercado de sistemas operacionais já começaram a se mexer para cuidar disso, provavelmente percebendo os benefícios dessa abordagem em termos de utilização de recursos de desenvolvimento, custos e consistência da interface de usuário.

O iOS é o exemplo mais evidente: Primeiro, porque reutiliza um bocado de código do Mac OS X em seu núcleo; segundo, porque a versão do iPad é só uma variante levemente modificada da versão portátil (sendo, inclusive, capaz de executar os mesmos aplicativos); e terceiro, porque as novidades que o Mac OS X “Lion” vai apresentar são essencialmente um “copiar e colar” dos recursos do iOS. A Mac Store até inclui vários aplicativos portados do iOS, mostrando claramente que os dois OS têm um destino em comum.

A Microsoft, por sua vez, também trabalha nisso, porém de maneira mais discreta. Seus vários sistemas operacionais não compartilham um mesmo kernel no momento, mas o port do Windows para ARM mostrado recentemente é algo nesse sentido. O .Net já é uma plataforma de desenvolvimento universal em todos os dispositivos da Microsoft. O Windows 7 vem com um suporte maior a telas sensíveis ao toque e à entrada com caneta, e o ainda não anunciado Windows 8 aparentemente vai se aproximar do estilo visual dos smartphones, incluindo uma loja de aplicativos.

O Google é o novato no mercado de sistemas operacionais, mas como cidadão de primeira classe em sistemas operacionais para dispositivos móveis ele optou por seguir os passos da Apple, portando seu sistema operacional para smartphones, o Android, para os tablets em sua versão 3.0 “Honeycomb”.

A triste situação do software criado por terceiros

O conceito de um sistema operacional unificado para todos os computadores pessoais se infiltrou mesmo nas mentes dos grandes participantes desse mercado, e eles obviamente estão trabalhando nisso. Mas um dos pontos principais da computação pessoal é o de oferecer máquinas flexíveis que se adaptem às necessidades de seus usuários. Logo, ter um sistema operacional universal (ou pelo menos uma plataforma de desenvolvimento universal) não basta. Criar uma plataforma universal de computação pessoal também implica em ter software feito por terceiros que funcione bem em todo lugar, sem a necessidade de recriar completamente partes dele (como a interface, por exemplo) cada vez que um novo tipo de computador pessoal é lançado.

E é aqui que os designs atuais fracassam.

Vamos pensar primeiro no que parece ser o caminho mais simples: botar os aplicativos criados pensando em smartphones para rodar em dispositivos mais pesados, como netbooks ou tablets. Como hoje temos hardware com mais recursos, isso deve ser algo trivial, não é mesmo? Bom, na verdade não é não. Os aplicativos são feitos pensando em um formato físico específico, com controles de tamanho fixo. As posições e os tamanhos são embutidos no código, seja em centímetros e polegadas ou pior ainda, em pixels. Logo, o único jeito de fazer um aplicativo para telefones usar mais espaço na tela sem reescrever completamente sua interface é usar os recursos de zoom, multiplicando posições e tamanhos cegamente sem saber o que representam, meio como a Apple faz ao rodar aplicativos do iPhone no iPad.

Esse procedimento (“upscaling”) realizado às cegas pelo sistema operacional, sem qualquer conhecimento do que vai realmente acontecer, não é uma boa ideia. Primeiro, porque há um desperdício de espaço na tela, com botões gigantes, menus gigantes e textos gigantes. Os dedos e os olhos do usuário, porém, continuam do mesmo tamanho (ou assim esperamos). Segundo, porque a usabilidade é totalmente destruída quando as pessoas precisam fazer grandes movimentações para ir de um botão para o outro, quando no telefone eles só precisavam mover o dedão. Terceiro, e talvez o ponto mais importante, porque você continua usando uma interface feita para telefones, simples ao ponto de ser complicada de usar em alguns momentos, porque foi feita para se encaixar em uma tela de 4”. Em uma tela grande, o usuário vai ficar se perguntando se faz algum sentido ter uma tela maior se os aplicativos não se beneficiam dela.

O último problema é particularmente interessante, porque nos faz perceber que as capacidades limitadas de hardware cerceiam a criatividade dos desenvolvedores, forçando-os a adaptarem seu software às limitações técnicas do hardware para o qual ele está criando o código. Portanto, embora possa parecer que aumentar automaticamente o tamanho da interface é o processo mais fácil, isso não é necessariamente verdade. Para fazer um uso pleno de certas capacidades do hardware, um software tem que ser desenvolvido tendo em mente o hardware que detém essas capacidades. Quando levados para hardware mais poderoso, os aplicativos para telefone não podem inventar novas funções que não eram úteis na tela de 4”. Por outro lado, é fácil imaginar que alguma complexidade seria escondida ao portarmos um aplicativo de um tablet para um dispositivo menor para que ele continue funcionando.

Como aumentar tudo automaticamente não é uma boa ideia, temos que encontrar um exemplo real de diminuição automática (“downscaling”) para ver se ela funciona melhor. E temos um: a Microsoft anunciou que o Windows 7 deve funcionar corretamente em netbooks e dispositivos com tela sensível ao toque. Só que, na prática, a coisa também não funciona. O Windows em si e os aplicativos que vêm nele até funcionam relativamente bem (embora o resultado não seja lá muito bom), mas os aplicativos criados por terceiros são um desastre de usabilidade. A maioria dos controles é pequena demais para ser usada com um toque do dedo, e até com o de uma caneta. Em uma tela pequena, como a de um netbook ou tablet, as barras de ferramentas e menus saem da tela, exigindo a rolagem constante da tela e uma maior navegação pelos menus para encontrar itens mais comuns. Resumindo: tudo é meio bagunçado, compacto demais e extremamente complicado. Esses aplicativos abusam desse tipo de hardware, e acabam se tornando quase impossíveis de usar.

De quem é a culpa? Mais uma vez, o problema é que o sistema operacional (ou, para ser mais exato, do kit de ferramentas da interface de usuário) tem que ajudar os aplicativos a se adaptarem aos dispositivos nos quais vão ser executados, sem ter a menor ideia do que esses aplicativos fazem e sem poder fazer nada sem violar um conjunto de especificações fornecidas por esses aplicativos. Os controles têm tamanhos fixos que não podem ser alterados sem que se arruíne o layout do aplicativo. As barras de ferramentas e os menus são desenvolvidos sem priorizar recursos, com base na ideia de que tudo vai caber na tela. Resumindo, os aplicativos se baseiam em um conjunto muito forte de hipóteses sobre o hardware no qual vão ser executados. Se essas hipóteses não se confirmarem, o resultado é uma falha de usabilidade.

Uma possível solução para o problema

Vamos resumir o que concluímos até agora.

Os sistemas operacionais estão lentamente começando a operar em vários tipos de computadores pessoais, mas os aplicativos de terceiros estão comendo poeira, já que suas interfaces ainda precisam ser recriadas para cada dispositivo. A recriação ocorre porque esses aplicativos não conseguem usar o espaço extra na tela de forma inteligente, nem conseguem se adaptar a tamanhos de tela reduzidos.

Fundamentalmente, as interfaces praticamente não conseguem usar capacidades típicas de hardwares que não foram levados em conta durante o desenvolvimento. A única maneira dos aplicativos se adaptarem a uma vasta gama de hardware é desenvolver esses aplicativos para máquinas poderosas primeiro, e depois dar um jeito de abrir mão de algumas funcionalidades da interface na hora de rodá-los em computadores menos poderosos para que eles continuem fáceis e agradáveis de usar. Essas alterações relacionadas à redução das capacidades do hardware deveriam ser tratadas pelo sistema operacional em tempo de execução, e não pelo desenvolvedor na hora de desenvolver o aplicativo.

E como isso funcionaria na prática?

Para adaptar interfaces de usuário ao hardware no qual elas vão rodar, o sistema operacional vai exigir do desenvolvedor algumas informações. O desenvolvedor teria que especificar os limites que realmente importam na interface, e deixar o resto por conta do sistema operacional. Por exemplo, ele não especificaria a posição e o tamanho de um botão em pixels, manualmente. Apenas diria “há um botão para cancelar no canto inferior direito da janela, e um botão de confirmação à esquerda dele”. Só isso. Cabe ao kit de ferramentas do sistema operacional decidir o tamanho desses botões, e onde eles se encaixarão com base nessas limitações. Uma possível limitação na hora de desenvolver jogos para dispositivos com tela sensível ao toque (e não especificamente para tablets ou telefones) seria “esses botões precisam ficar na borda da tela (para uso com os dedos), e próximos um ao outro (para uma movimentação rápida do polegar entre um e outro)”.

Agora que tem um certo poder para decidir como vai renderizar a interface, o sistema operacional tem que conseguir usar esse poder com sabedoria. Como estamos falando em levar aplicativos de uma tela grande para uma tela pequena, a principal tarefa do sistema operacional será a de remover controles da interface quando o espaço na tela for menor do que os benefícios de usabilidade de ter os controles à disposição. Mas quais controles remover, quando e como?

O desenvolvedor da interface pode definir algumas prioridades. Nós todos fazemos isso na hora de criar uma barra de ferramentas para um aplicativo que vai rodar no desktop: os botões à direita na barra de ferramentas são os primeiros a desaparecer quando o tamanho da tela é menor, e o usuário só os nota depois de examinar os botões à esquerda (presumindo que o usuário leia da esquerda para a direita), portanto devemos colocar só as funções menos importantes nessa posição. Mas quando falamos em um aplicativo que deve funcionar em tudo, de um desktop a um telefone com tela sensível ao toque, essa regra não é mais suficiente. Ponha uma suíte de escritório moderna para rodar em um telefone sem fazer modificações nela, e você vai ganhar uma tela cheia de menus embolados e barras de ferramentas truncadas.

Para evitar esse problema, o sistema operacional precisa ser capaz de ocultar todas as barras de ferramentas, menu e status, além de agrupar botões em um menu pop-up para ocupar menos espaço na tela, oferecendo acesso direto apenas às funções mais usadas. Não apenas ocultar, mas por vezes retirar funcionalidades dos menus para que eles fiquem menores. Todas essas possibilidades de simplificação do aplicativo irão afetar diversos controles e prejudicar um pouco a usabilidade, mas em troca o usuário vai ganhar espaço na tela. É claro que não há como um programa de computador tomar decisões sozinho; ele precisa de alguma ajuda do desenvolvedor, que vai descrever quais controles podem ser ignorados e quais precisam aparecer de qualquer jeito.

Vejamos um processador de texto, por exemplo.

É óbvio que a área mais importante é a que abriga o documento, e ela não pode ser ocultada. Agora vamos examinar os diversos controles que o usuário tem à mão, mas que não são essenciais:

• Em um dispositivo pequeno, onde todos os aplicativos ocupam a tela toda, não é necessário especificar o nome do aplicativo aberto na barra de título. O menu no canto superior esquerdo também é meio desnecessário;

• A barra de menu é usada para funções que não são utilizadas com frequência, como quebras de página. Caso necessário, essas funções podem entrar em um botão retrátil, como a seta no canto superior esquerdo;

• No dia a dia, a maioria das pessoas só vai usar a barra de formatação. Se precisamos poupar espaço, podemos nos livrar das outras duas;

• Nessa barra que vai ficar, nem tudo tem o mesmo peso. Só usuários avançados usam estilos, então poderíamos colocá-los em uma grande caixa de combinação (“combo box”) quando houver pouco espaço, e exibir apenas o botão que vai abri-la. Se o espaço for muito pequeno mesmo, talvez até possamos eliminar a função de estilos por completo;

• Se isso ainda não for suficiente, podemos abrir mão das listas de fontes e tamanhos de fontes, ocultando-as com um botão para a configuração de fontes;

• Podemos ocultar as réguas e remover os botões de indentação;

• Podemos ocultar as barras de rolagem e os controles de zoom, levando em conta que dispositivos pequenos vêm equipados com telas multitoque e que portanto esses controles são supérfluos. Ficaria só um pequeno indicador durante a rolagem, mostrando em que parte do documento o usuário está;

• Agora podemos mesclar os botões de alinhamento em um menu pop-up, exibindo apenas o alinhamento aplicado no momento;

• Podemos ocultar as réguas e remover os botões de indentação;

• Podemos remover as configurações de realçar texto e de cor de fundo.

Eis o resultado até aqui:

Isso seria aceitável para uma suíte de escritório para smartphones, e nosso software seria capaz de se adaptar a desktops, smartphones e tudo o que estiver entre eles sem a necessidade de reescrever a interface.

E então, como fazer para dar conta da portabilidade do software sem ter que fazer modificações nele? Definindo numericamente a importância de cada recurso em comparação ao espaço que ele ocupa, e deixando o sistema operacional fazer o trabalho de remoção automática com base nas prioridades e no tamanho da tela. Levaria mais tempo para essas interfaces serem desenvolvidas (por causa do processo de atribuição de prioridades), mas eles se adaptariam a uma variedade muito maior de dispositivos após o estágio de design. E nós poderíamos finalmente ter uma plataforma de computação universal, acabando de vez com essa bobeira de “meu smartphone é maior do que o seu desktop”.

Créditos a Hadrien Grasland – osnews.com

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>