Tableless - Padrões Web com Pastel e Caldo de Cana

Posts da TAG ‘Browsers’

« Posts antigos
Posts recentes »

Quem precisa de versão mobile?

Parece ser um erro comum dos novatos criar versões diferentes do mesmo site.

O ano era 1997. Eu e e todo mundo que eu conhecia usávamos Netscape Navigator. Foi o ano em que, pela primeira vez, fiz um site sozinho. Tudo, atendi o cliente, preparei textos, fotos, fiz o layout, se é que se pode chamar aquilo de layout, criei uma conta no Geocities e publiquei. Em seguida entrei no Yahoo! e cadastrei o site, para que aparecesse nas buscas.

Depois de alguns dias recebi um e-mail do Yahoo! dizendo que o site não poderia ser publicado no diretório porque não funcionava no Internet Explorer. Continuar lendo »

27 Comentários

Lidando bem com os bloqueadores de pop-up

Todo mundo que já experimentou ama bloqueadores de pop-ups. Navegando há anos com Opera e Konqueror e usando Firefox para acessar o Gmail, ainda me assusto quando preciso navegar no IE, seja num cybercafé ou na máquina de um amigo. Como é que as pessoas podem conviver com aquilo? Pop-ups são muito chatos, e se você não acha é porque ainda não experimentou viver sem eles tempo o suficiente.

Por outro lado, o advento dos bloqueadores de pop-up trouxe alguns desafios bastante específicos para o desenvolvedor. Por exemplo, o desafio de fazer sites compatíveis com qualquer navegador quando é obrigado a usar ferramentas de terceiros. É o caso, por exemplo, de alguns sistemas de pagamento nacionais, ferramentas essenciais para o desenvolvimento de qualquer e-commerce brasileiro. O fato é que muitos desses sistemas exigem dos seus usuários a exibição de um pop-up, seja em uma tela de pagamento ou, o que é mais comum, no recibo.

Para complicar, esses sistemas geralmente são submetidos a complexos e burocráticos processos de homologação, onde geralmente a pessoa que vai aprovar seu sistema usa Internet Explorer para Windows e não vai estar muito interessado em ouvir seus argumentos a respeito da inacessibilidade dos pop-ups. Vamos então criar uma solução para que o usuário de navegadores sem bloqueador de pop-ups possam ver normalmente seus pop-ups enquanto os que possuem bloqueador sejam servidos com um confortável link para o endereço do pop-up. Além disso, vamos fazer que aqueles que escolheram o gerenciamenteo inteligente de pop-ups possam ver um pop-up ao clicar no link, mantendo o layout do recibo como foi planejado pelo sistema de pagamento, e o que escolheu bloquear todos os pop-ups possa ver o conteúdo na mesma janela.

Primeiro passo:

Telefonar e escrever para pessoal do sistema de pagamentos, avisando que pop-ups são uma solução ruim. Demonstre sua indignação pelo fato de o sistema deles precisar de uma ferramenta tão estúpida. De quebra, aproveite para perguntar como fazer o site deles, o módulo administrativo, ou o que mais eles tenham feito para que você e seu cliente acessem funcionar em seu navegador. Pergunte porque o manual fala sobre Internet Explorer e Netscape 4, mas não fala do Safari ou do Firefox. Apresente dessa maneira o Opera e o Mozilla. Se muitos de nós fizermos isso, eles vão ter que começar a considerar esses navegadores ao criar seus sistemas.

Segundo passo:

Entender os fatos básicos. Agora que você já ajudou a tornar a web um lugar melhor, vamos resolver o problema imediato do nosso cliente. Primeiro vamos ver como criar um link de pop-up que seja acessível a quem não quer ou não pode exibir pop-ups. Links para pop-ups geralmente são criados assim:

<a href="javascript:void(open('http://www.atipico.com.br','nova','width=800,height=600'))">Atípico</a>

O problema é que quem não tem javascript em seu navegador ou bloqueou todos os pop-ups não pode acessar o link. Muita gente por aí tem usado assim:

<a href="http://www.atipico.com.br" onclick="window.open(this.href,'nova','width=800,height=600');return false;">Atípico</a>

Assim, o link passa a ser um link HTML comum. Para quem tem javascript disponível, o evento onclick vai abrir o popup e o return false ao final vai cancelar o click, fazendo com que a página seja aberta apenas no pop-up, e não na janela atual. Apesar da beleza e da simplicidade, este código tem dois problemas. O primeiro é que o Internet Explorer 5.0, em algumas situações, não lida muito bem com comandos separados por ponto-e-vírgula em atributos HTML. O segundo, mais sério, é que navegadores como Konqueror e Firefox não interrompem um script ao bloquear um pop-up. Então, se o Konqueror estiver configurado para bloquear todos os pop-ups, o pop-up não vai aparecer, e o return false vai ser executado, fazendo com que o link também não seja carregado na janela atual.

De fato, o código acima era muito usado antes do advento dos bloqueadores de pop-up, para manter o site acessível en navegadores sem javascript. Ele funciona muito bem se não houver javascript disponível, mas falha em alguns navegadores se houver javascript e o bloqueador de pop-ups estiver habilitado.

Para entender mais de perto a problemática vamos verificar como os navegadores se comportam ao bloquear um popup. Para isso vamos usar o seguinte código:

<script>
    alert("passo 1")
    window.open("http://www.atipico.com.br","nova","width=800,height=600")
    alert("passo 2")
</script>
<script>
    alert("passo 3")
</script>

Fazendo o teste com este script você pode notar como os navegadores se comportam de maneira diferente ao bloquear um pop-up. Testei no Opera 7.52, no Firefox 0.8 e no Konqueror 3.2.2, todos em Linux. O Mozilla e o Konqueror exibem os três alerts. Ou seja, o pop-up é bloqueado mas o script segue sua execução normal. No Opera são exibidos os alerts 1 e 3. O Opera, portanto, interrompe a execução de um script ao bloquear um pop-up, mas executa normalmente outros scripts na mesma página. O Internet Explorer com a Google Toolbar se comportou de maneira idêntica ao Mozilla e ao Konqueror.

Terceiro passo:

Vamos manter nosso pop-up automático, e inserir um link para abrir pop-up que poderá ser usado por quem usa bloqueadores (ou mesmo por alguém que tenha fechado o pop-up por engano):

<script>
    pagina="http://www.atipico.com.br"

    function abrir(){
        newWindow=window.open(pagina,"nova","width=800,height=600")
        if(newWindow)return false
    }

    abrir()
</script>
<a href='http://www.atipico.com.br' onclick='return abrir()'>Abrir</a>

Aqui criamos uma função, abrir, que abre o popup. Em seguida a executamos. Se não houver bloqueadores o pop-up será exibido automaticamente neste passo. Exibimos então um link “Abrir” que executa novamente a função quando clicado. Aqui está toda a mágica, o onclick do link contém return abrir(), ou seja, o evento será tratado de acordo com o retorno da função. O click somente será cancelado se a função retornar false.

Agora note que a função tem duas linhas. Na primeira abrimos a nova janela (pop-up) e armazenamos o resultado na variável newWindow. Na segunda linha testamos o valor de newWindow, se existir retornamos false. Assim, acompanhe nosso programa em três situações diferentes: primeiro, se não houver bloqueadores de pop-ups ou se o bloqueador estiver configurado em smart policy, ou seja, permitir os pop-ups requisitados por você. Neste caso, a primeira linha da função abre a janela e armazena o objeto na variável newWindow. A segunda linha testa o valor de newWindow, que existe, e retorna false, cancelando o click. Neste caso o usuário verá o pop-up e nada acontece com a janela original, perfeito. O segundo caso é o de bloqueadores de pop-ups que não permitem pop-up algum, mas não interrompem a execução do script. Neste caso, o pop-up não será aberto. Ao chegar à segunda linha da função, new Window é testada, e não existe. A função não retornará valor (na verdade retornará undefined, mas isso é outro assunto). O click não será cancelado e o usuário verá a página solicitada na janela original. A terceira situação é o caso dos bloqueadores de pop-up que interrompem a execução do script. Nestes o script sequer chegará à segunda linha da função, o javascript será interrompido e o evento não será cancelado, uma vez que o script sequer chegou a retornar algum valor. O resultado será idêntico ao segundo caso.

Há ainda uma quarta situação, a dos navegadores que não possuem javascript habilitado. Neste caso o link vai se comportar como um link normal, sem nenhum problema para o usuário (embora eu duvide que alguém sem javascript consiga usar qualquer sistema de pagamento eletrônico disponível no Brasil.)

Quarto passo:

Pra quê um quarto passo? O código anterior já funciona muito bem, resolvendo nosso problema. Bom talvez você seja curioso o suficiente para querer complicar um pouco as coisas. A questão agora é: como exibir conteúdo de acordo com o status do pop-up. Isto é, por exemplo, se não houver bloqueador de pop-up não exibir o link “Abrir”, uma vez que o usuário verá o pop-up automaticamente. Pois bem, vamos lá:

<script>
    pagina="http://www.atipico.com.br"

    abriu=false

    function abrir(){
        newWindow=window.open(pagina,"nova","width=800,height=600")
        if(newWindow){
            abriu=true
            return false
        }
    }

    abrir()

</script>
<script>
if(!abriu)document.write("<a href='http://www.atipico.com.br' onclick='return abrir()'>Abrir</a>")
</script>

Agora usamos uma variável, abriu, para guardar o status do pop-up. Começamos o script atribuindo false a esta variável. Depois, dentro do if que testa o pop-up, setamos seu valor para true. Se o pop-up for aberto o valor de abriu será true, caso contrário será mantido o false original.

No segundo bloco script testamos o valor de abriu. Se o pop-up não foi aberto, escrevemos no documento o link para abrí-lo. Colocamos esta linha em um segundo bloco script para que seja executada mesmo que o bloqueador interrompa o primeiro script ao cancelar o pop-up.

O script já faz o que propusemos, exibe o link apenas se o pop-up não for aberto automaticamente. Mas agora ele falha em navegadores sem suporte a javascript. Iso é fácil de resolver, basta colocar, depois dos scripts:

<noscript>
    <a href="http://www.atipico.com.br">Abrir</a>
</noscript>

Palavras finais:

Como você viu, lidar com bloqueadores de pop-up é tarefa trivial, e você pode oferecer conteúdo ao seu usuário no formato que ele escolheu ver, pop-ups para quem não se importa com eles, ou mesmo para quem os deseja, e links comuns para quem escolheu não ver pop-ups. Claro, continuamos achando que pop-ups não são uma boa ferramenta, mas como você não pode trabalhar sempre sozinho, isto pode lhe ser útil ao lidar com código de terceiros, como os citados sistemas de e-commerce.

O código nesse artigo foi escrito apenas para estudo. É claro, quando for para valer, você deve escrever código melhor que o meu. Seus links precisam ter um atributo title que descreva bem seu destino, e “Abrir” não é um bom texto para se colocar em um link. Você sabe também que, neste último exemplo, depois de if(!abriu) você pode fazer o que quiser, e também deve saber que não é bom escrever scripts assim, no meio do seu HTML, e que document.write não é uma boa maneira de se exibir conteúdo. Esperamos que estas idéias lhe sejam úteis. Se você desenvolver algo útil com isso conte pra gente.

5 Comentários

Sites para Dispositivos Móveis - MediaType

Felizmente, com a ajuda dos Web Standards, o trabalho para criar um site ficou muito mais fácil, rápida e o mais importante, divertida.
Hoje, você troca de layout a hora que quiser, sem se preocupar em ter que refazer todo o código e programação. Eles já estão feitos, por que ter que recriá-los? Então, você troca apenas 1 arquivo CSS, e seu site muda completamente, sem dor de cabeça, apenas mudando a lente de formatação.

E com as qualidades do CSS, também se tornou fácil fazer várias vesões de um mesmo site para diversas medias. O que eu quero dizer com isso? Muito simples… Antes, se você quisesse prover para seu visitante uma versão do seu site para imprimir, você faria uma versão do seu layout mais enxuta, sem as informações que se tornariam desnecessárias uma vez impressas. Teria que refazer o HTML, tirar partes de código e etc… Hoje, você simplesmente cria um CSS para a media de impressão, e pelo CSS oculta os objetos que você quiser. Muito mais fácil, muito mais prático.

Do mesmo jeito que você faz uma versão do CSS para site ser impresso, você fará uma folha de estilo para os HandHelds. Ou seja, o camarada que entrar usando um dispositivo móvel, terá uma versão totalmente compatível, e sem informações que não lhe é interessante quando está usando esse dispositivo.
A mecanica é mesma. Com CSS você oculta as informações não são interessantes para o usuário de mobiles. Por exemplo, se o cidadão acessar o site da UOL com um mobile, não é interessante para ele, ver boa parte de cabeçalho do UOL. Como por exemplo os links de ASSINE UOL ou links para o BATE-PAPO. Essas informações seriam facilmente ocultadas.

Você fará então, várias versões de CSS para vários tipos de Medias. Usará o mesmo XHTML, sem tocar em nenhum código de programação, manipulando totalmente o site para se adequarem às Medias desejáveis.
Suas tags para linkar os arquivos CSS ficarão desta maneira:

Screen: Para Desktops
<link rel=”stylesheet” type=”text/css” href=”screen.css” media=”screen” />
Print: Para Impressão
<link rel=”stylesheet” type=”text/css” href=”print.css” media=”print” />
HandHelds: Para HandHelds, PDA´s, etc
<link rel=”stylesheet” type=”text/css” href=”handheld.css” media=”handheld” />

Perceba que em todas as linhas, há um atributo MEDIA. É com esse atributo que diremos ao navegar onde ele deve aplicar o CSS. Se o camarada visita o site com um dispositivo móvel, com um navegador que seja de acordo com os Padrões (óbvio), vai usar automáticamente para renderizar o site, o CSS de HandHelds, em vez de Screen. Você não terá trabalho para fazer um script que chaveia nem nada parecido, como fazem alguns sites hoje em dia. Esse chaveamento será feito automáticamente, pelo navegador.

Trabalho? Quase zero. Você teve apenas que criar um novo CSS, escondendo objetos, diminuindo e modificando outros. Alguns mais ousados, farão uma versão que segue o estilo do site visto por desktops, mas mais direcionado a usuários de Mobiles, deixando mais confortáveis.

Compare as duas imagens abaixo. Usei como modelo o site do Opera, eles fizeram um belo trabalho. Primeiro, um screeshot do site visto de um monitor, com MediaType Screen.

Opera visto pelo Desktop

Agora, confira o mesmo site, só que visto com o CSS destinado a HandHelds. Perceba as diferenças e veja que eles ocultaram boa parte das informações, como por exemplo, aquela chamada enorme sobre o download do Opera 8.5, que é interessante apenas para os usuários de Desktop, não para usuários de Mobiles.

Opera visto em um HandHeld

Eles aproveitaram também para rebuscar o design para esses dispositivos. A experiência do usuário, com certeza será satisfatória. É confortável de navegar. Você pode trabalhar melhor outras partes do desenvolvimento, como por exemplo, estudos de usabilidade. Você tem toda liberdade que o CSS pode lhe dar.

Propriedades CSS mais usadas

Todas as propriedades do CSS estarão disposníveis para o uso na manipulação para qualquer media. Claro, na media screen é que você usará mais largamente os mais variados tipos de propriedades que o CSS concede. Na media screen, as propriedades que você mais usará será a WIDTH, HEIGHT e DISPLAY.

Width e Height são propriedades que serve para definir largura e altura, respectivamente. Elas tem duas variação, onde você define qual largura/altura máxima que dado objeto pode ter. São elas max-width e max-hight.
Então, você definirá no CSS de handheld, qual a largura máxima, que por exemplo, o body deverá ter.

body {max-width: 240px;}

Já a propriedade display, será muito usada para ocultar os objetos. Muitas informações que aparecem em alguma parte do layout, muitas vezes não são úteis para os usuários de mobiles, portanto, ocultar essas informações é um favor que você faz para os usuários.

Há algo sobre o assunto no site do Opera, não custa nada dar uma olhada… Visite e leia.

Testando

Você não precisa ter um dispositivo móvel para conseguir saber como seu site se comportará. Basta simplesmente usar o sistema de SSR do Opera, ele é ativado apertando a combinação de teclado SHIFT + F11.
Se você já tem um CSS para media de HandHeld, ele ativará automáticamente esse CSS no SSR.

Meu conselho é você primeiro tudo testar o site sem CSS para HandHeld para ter uma noção de como ele será exibido sem formatação específica. Depois, aplique um CSS para HandHelds, e compare a diferença. Veja como você tem mais controle sobre o layout.

E atenção… Não são todos os browsers que tem um sistema tão bom quanto o Opera. E, hoje em dia, apenas o Opera e o MiniMo (uma versão do Mozilla para mobiles) tem amplo suporte de CSS. O resto dos browsers tem pouca ou quase nenhum suporte. O IE para HandHeld por exemplo, não tem tanto suporte quanto os outros dois, por exemplo, ele não reconhece MediaTypes.

Vamos nos dar mais atenção a esse mercado. Ele está crescendo e a cada ano surgem novas possibilidades. É um ramo que cresce rápido, e não vai demorar muito você ver qualquer pessoa na rua visitando algum site para consultar um mapa ou procurar qualquer tipo de informação. É muito importante que os desenvolvedores atentem para esse grande caminho.

5 Comentários

Flock 1.0 - agora dá para usar

O Firefox é o browser do meu coracão. Não vivo mais sem suas extensões. Se você é desenvolvedor e usa Firefox, sabe do que estou falando.
Só que eu não sou apenas desenvolvedor. Nas horas vagas, sou gente normal. Gosto de passar uma parte do meu tempo navegando pelos meus sites prediletos. Por isso, eu gastava algumas horas procurando por extensões que me deixassem mais ligado em sites como Flickr, Twitter e Del.icio.us.
O Flock, durante algum tempo, tinha a promessa de ser um browser que facilitasse nossa relação com os serviços online. Até então, pelo menos para mim, ele não tinha alcançado este objetivo. Parece que tudo mudou de figura. Foi lançado a versão 1.0 do Flock para Windows, Mac e Linux e pelo menos até agora, estou gostando bastante.

Depois da instalação, ele me perguntou se eu gostaria de importar meus favoritos e outras configurações do Firefox ou Safari. Disse para pegar tudo do Firefox. Isso foi feito sem o menor problema.

Extensões do Firefox

Mesmo o Flock sendo baseado no Firefox, minha primeira preocupação foi testar as extensões que eu mais uso no Firefox. Nas versões anteriores do Flock, muitas delas davam defeitos e eu acabava não migrando de browser por conta disso. Mas agora, depois dos testes, parece que a versão 1.0 está totalmente estável para o uso de extensões do Firefox.
Instalei aqui: ColorZilla, Measureit, Web Developer, Gmail Manager, Mouse Gestures e FoxMarks. Todas elas funcionaram sem problemas.

Cadastro e uso dos Serviços Online

Achei um pouco complicado de cadastrar meus serviços online. Demorei para notar que eu tinha que entrar no site do serviço, me deslogar e logar novamente para ele detectar o login e assim cadastrar no Flock. Entretanto, depois disso, tudo foi bem transparente. A interface é bem acabada, mesmo assim achei tudo bem apertado no painel lateral. Talvez exista a possibilidade de customizar essa opção.

Contudo, há muito o que melhorar com a interface para facilitar o uso de alguns serviços. Não descobri uma maneira fácil de dar Reply em mensagens do Twitter, a não ser digitando na unha. Ele também não dá nenhuma pista de qual seja o apelido dos usuários. O que dificulta se você quer responder a mensagem do seu amigo.

Já o uso do Flickr é sensacional desde as versões anteriores do Flock. Mesma coisa para o Del.icio.us e outros serviços. Foi implementado também serviços como YouTube.

Outros pontos

O visual geral do Flock, na minha opinião, é melhor que a do Firefox. E há suporte para a instalação de outros temas.

Há uma parte que gostei muito chamada My World. Seria uma espécie de página onde você fica por dentro do seu “profile” do Flock. Confere suas contas de serviços, vê suas visitas e movimentações nos serviços cadastrados e etc…

Gostei bastante também da interface de blogging. Integrei o Flock com o WordPress do Tableless. Ficou mais fácil blogar.

Se você quiser testar o Flock, indico, pelo menos por agora. Vou dar mais pitaco sobre ele conforme vou usando pelo meu Twitter.

Tags: , , , , ,

10 Comentários

Sobre Internet Explorer para Mobile - Breve impressão

Desde que adquiri um MotoQ (se lê MotoQUIU) eu venho usando o Opera Mobile como browser padrão. Ao contrário da versão pra desktops, o Opera Mobile é pago. Por este motivo, quando a data expirou, eu resolvi usar por um tempo o Internet Explorer.
Descobri que a forma com que o IE Mobile renderiza as páginas é tão boa quanto a do Opera Mobile. A velocidade de navegação também é ótima.

O Opera usa muito um sistema que eles chamam de SSR,que em teoria, melhoraria (ou pelo menos tentaria) a visualização de sites em dispositivos móveis. Acontece que esse modo deixa o site muito, mas muito feio. Neste caso, tive a impressão de que o Internet Explorer renderiza melhor os sites que não foram feitos para mobile.

Para quem quer dar uma ajuda para o pessoal que usa browsers mobiles, existe uma metatag chamada MobileOptimized:

<meta name="MobileOptimized" content="sualargura" />

Essa metatag é usada principalmente pelo Internet Explorer Mobile para otimizar melhor o site quando visto de SmartPhones, PocketPCs, etc. O valor colocado ali no atributo “content” deve ser a largura que o browser deve limitar seu layout quando visto de um mobile.

Aviso aos navegantes: fazer image-replacement usando text-indent não funciona no IE para Mobiles. Parece que ele não reconhece o text-indent, o que faz com que o texto fique por cima do logo.

A qualidade de rederização das fontes também achei melhor que a do Opera Mobile. Achei as fontes muito mais nítidas e legíveis.

Uma coisa ruim que achei o IE para Mobiles é a falta de abas. Isso seria muito útil. Normalmente estou sempre visitando e usando mais de dois sites simultâneamente. E sair de um para visitar o outro é uma alterativa terrível. Isso sim me faria voltar para o Opera.

11 Comentários

Mobilidade na cabeça

Ontem, depois do lançamento do iPhone e de ter visto suas funcionalidades (nem tão novas assim, mas reinvatadas de verdade), fiquei pensando em uma funcionalidade em particular: navegação na internet. Quem assistiu o Keynote viu o camarada navegando de verdade com um browser de verdade (Safari) e tendo uma experiência realmente boa. O browser carrega o site inteiro, lendo XHTML e CSS, nada de SSR ou qualquer coisa parecida e é renderizado como se fosse uma miniatura na tela, mas a formatação é integral, como se estivesse sendo visualizado de um desktop. Sim, ficou impossível de ler, mas isso foi resolvido quando o nosso camarada tocou duas vezes no lugar que ele gostaria de ler e o browser deu um ZOOM, possibilitando a leitura.
Essa experiência é muito comum hoje em dia, só que em vez de dedos, você estaria usando uma Stylus (aquela canetinha nojenta), muito pior de manejar do que seus dedos.

A impressão que eu tive sobre a experiência de navegação no iPhone é ótima. Será um dispositivo que os desenvolvedores não terão que se preocupar com compatibilidade, você nem vai precisar fazer uma versão especifica para mobiles (no caso do iPhone). Sim! Você ainda precisa se preocupar com desenvolvimento de sites para dispositivos móveis. O iPhone não é o único dispositivo do mercado, infelizmente. :-)

Também hoje, o Yahoo! liberou para download um pacote de programas direcionados para celulares. O Yahoo! sempre foi antenada quando se trata de mobiles. E você sabe que eles fazem um trabalho bem feito. Sem comentar do Opera, que é um dos melhores (ou melhor) browsers para dispositivos móveis que existe.
Mobilidade é uma coisa que todo mundo precisa e quer. Quem tem um celular hoje, não consegue mais viver sem. Quem tem um celular com conexão à internet também não consegue viver sem. E assim o público vai mudando e se inovando. Aí é onde a coisa fica mais interessante.

Já falei e repito: pra mim, este ano será da mobilidade. Haverá mais interesse nesse mercado, mais procura, mais agitação. Se as empresas acima estão dando uma certa atenção pra isso, já é motivo para mexermos nossos ossos e corrermos atrás do prejuízo desde agora.

5 Comentários

Breve introdução: XHTML Mobile Profile

XHTML MP é um subset do já conhecido XHTML. Ele é baseado em um outro subset de XHTML chamada XHTML Basic. O XHTML Basic é uma versão simplificada do XHTML definido pelo W3C. Ele foi feito especificamente para dispositivos com baixo poder de processamento como celulares, PDAs, pagers etc… O XHTML Basic não contém algumas características que esses dispositivos dificilmente suportam, como por exemplo: Frames, Folhas de Estilo em Cascata e scripts.

O ponto forte do XHTML MP é trazer para os dispositivos móveis tecnologias atuais para criar uma experiência melhor ao navegar. Antes do nascimento do XHTML MP, os desenvolvedores para internet móvel usavam WML e WMLScript para criar sites em WAP. Enquanto isso, os desenvolvedores para a internet convencional trabalhavam com HTML/XHTML e CSS para construir web sites.

Com a vinda do XHTML MP, a linguagem da internet sem fio e a linguagem da internet convencional finalmente convergiram. XHTML Mobile Profiles juntamente com o WCSS deram mais flexibilidade para os desenvolvedores de sites para dispositivos wireless. Agora, desenvolver para dispositivos móveis ficou tão fácil quanto desenvolver web sites normais. Não é mais necessário ter dispositivos ou softwares especificos para testar seu projeto. Não é mais necessário aprender outra linguagem, é tudo XHTML e CSS, claro, com mudanças específicas para mobiles.

Assunto interessante. Dá muito pano para manga.
O texto não está tão elaborado porque é um rascunho sobre algumas coisas que ando lendo. Como não tive tempo de fazer um texto mais completo, acabei postando esse mesmo.

obs.: quase uma tradução do texto que está em XHTML MP. E uma prévia para breves lançamentos na Visie.

10 Comentários

Podcast #18 - Opera 9, Wasabi, Songbird e Semântica

Nesse podcast falamos um pouco sobre o lançamento Opera 9 Preview… vocês perceberam que ele veio uma semana depois de sair o Beta 2 do IE7? :-)
Falamos sobre o Wasabi! Tá sabendo?
Falamos sobre o Songbird: Um player de Mp3 Open Source baseado no motor do Firefox. Parece ser interessante, embora eu não tenha gostado muito do programa. Achei meio dificil.

Tamanho: ~27,2Mb
Tempo: ~29m43

Aconselhamos você a inscrever nosso Feed no seu agregador preferido, para facilitar seu acesso às novidades, ou simplesmente baixe o mp3 direto.

Estou me esforçando para que o arquivo fique o menor possível. Se você souber de algum bom programa que faça o trabalho de comprimir o arquivo mp3, por favor, diga.

52 Comentários

Principais pontos da Acessibilidade na Web

Quando ouvimos falar de sites acessíveis, logo imaginamos sites que podem ser acessados por pessoas com necessidades especiais. Isso é um grande erro que não podemos cometer. Ao termos essa atitude, negligenciamos uma série de outros fatores que são extremamente importante para a boa acessibilidade do site.

Abaixo, vamos tentar resumir os principais pontos que a Acessibilidade na Web alcança.

Diversos Dispositivos

Hoje o meio mais comum de navegar pela Web é usando um Desktop, ou seja, um Computador pessoal. Mas de uns tempos para cá, essa realidade vem mudando.

Os dispositivos móveis estão sendo muito difundidos e com isso ganham mercado entre os usuários. Hoje, em shoppings, aeroportos e outros lugares com alguma conexão sem fio, já podemos ver pessoas acessando a internet com variados Handhelds.

Há também o surgimento das WebTV´s e outros aparelhos semelhantes que permitem o usuário acessar a internet, usando um aparelho de televisão como dispositivo de saída.
Não é só a TV que ganhou a conexão com internet, microondas e geladeiras também foram privilegiadas. Com o tempo, isso se tornará cada vez mais comum.

A tendência é que cada vez mais surjam novos dispositivos acessando a web.

Diversas Plataformas

Quando você ouve sobre diferentes plataformas, alguns nomes lhe vem na cabeça, como Windows, Linux ou MacOS. Esquecemos de que os HandHelds, Tables ou outros dispositivos, usam seus próprios Sistemas Operacionais. O Palm por exemplo usa o PalmOS, o PocketPC usa Windows Mobile e a Internet Tablet Nokia 770, usa um sistema baseado em Gnome e Linux.

O que quero dizer, é que muitos desenvolvedores, ao fazer algum sistema para internet, usam algum tipo de sistema proprietário, favorecendo apenas uma plataforma. O pior, é que nenhuma versão alternativa é disponibilisada, restringindo muitos usuários.

Diferentes Browsers

Atualmente, os fabricantes de browsers, estão tendo um certo cuidado com a abordagem de padrões do W3C e plugins de terceiros.
Mas, infelizmente, muitos desenvolvedores ainda fazem a implementação dos sites se guiando pela metodologia antiga.

A Abordagem dos padrões é extremamente importante para que haja um nível de compatibilidade aceitável, não só entre navegadores de uma mesma plataforma, mas principalmente, entre navegadores de outros dispositivos. Usando metodologia antiga, site fatalmente necessita de uma versão para handhelds. Já um site que foi construído baseando-se nos Web Standards, fica melhor acessível mesmo não havendo uma versão especifica para esses dispositivos.

Todas as Pessoas

Atualmente, o acesso à internet por pessoas com algum tipo de deficiência física cresceu absurdamente. Os leitores e sintetizadores de tela também melhoram muitos seus sistemas. O que ainda continua parado, é a maioria dos sites que não atentam para pequenos detalhes que melhorariam muito a navagabilidade desses usuários.

Existem robôs que avaliam o nível de acessibililidade tem seu site. Eles te dão sugestões e te mostram alguns aspectos que devem ser levados em consideração.

A Acessibilidade na web é um assunto muito amplo, e que deve ser estudado com certo interesse pelos desenvolvedores.

Leia Mais:

10 Comentários

Sites para Dispositivos Móveis - Breve introdução

Você tem celular? De acordo com a Teleco, em novembro de 2005, havia mais ou menos 82.351.644 de celulares. Ainda me lembro de quando eles eram artigos de luxo, mesmo sendo grandes e pesados.
Hoje, por um preço razoável, você consegue celulares que tiram fotos e fazem outras coisas que nem James Bond ousava imaginar. E quer saber da melhor? Esse é só o começo.

Aparelhos com essas e outras possibilidades aparecerão. Os HandHelds com funcionalidades iguais as de um Desktop estarão em alta. Pessoas acessarão a internet de qualquer canto… não serão dependentes dos poucos HotSpots. Conexões como Wi-Max não serão novidade. Ninguém arregalará os olhos quando você tirar um Palm ou PPC do bolso para anotar algo e enviar por email, pelo contrário. A internet estará espalhada em cada bolso, em cada palma de mão.

O Google acabou de lançar uma versão do seu webmail para mobiles. Sem contar com sua versão de busca para Mobiles. O Flickr também tem sua versão para dispositivos móveis. Isso mostra que os grandes, de uma maneira ou de outra, estão preparados para essa nova etapa.

Como introdução a criação de sites para esses dispositivos, criamos dois artigos que poderão ajudar o desenvolvedor. É importante que comecemos a fazer da maneira certa. Ter em mente suas possibilidades, seus limites. Um dos artigos fala sobre SSR - Small-Screen Reader. O outro fala um pouco sobre MediaType para HandHelds.

13 Comentários
« Posts antigos
Posts novos »

Sobre Internet Móvel

Seção do tableless destinada a desenvolvimento web para dispositivos móveis. Entenda as características do mundo móvel e seus dispositivos.

Sobre Wordpress

Wordpress é uma plataforma de publicação de conteúdo grátis baseada em padrões web e usabilidade. Leia artigos técnicos sobre Wordpress aqui.

Voltar para o topo

Outros posts

Aprenda

Histórico