Bruno Dulcetti



Arquivos:

Categorias:

  • Amizade:

  • Artigos

  • Links:

    O meu, o seu, o nosso espaço!

    » Dia Mundial da Usabilidade

    Marca do WUD 2008

    Uma embalagem que não abre direito ou um produto difícil de usar. Quem já não passou por um problema desses? Com o objetivo de despertar a atenção das empresas e dos consumidores para essas questões foi criado o Dia Mundial da Usabilidade. Este ano o tema do evento, que é realizado em várias cidades do planeta no mesmo dia 13 de novembro, é “Transportes”. O Rio de Janeiro mais uma vez comemora a data com uma noite repleta de palestras sobre o assunto com especialistas de design e usabilidade.

    O evento, que tem como finalidade a valorização da facilidade de uso de produtos e serviços no cotidiano, traz apresentações de casos de sucesso de projetos aeronáutico, ferroviário e soluções de transporte para o trânsito saturado das cidades.

    Na primeira edição, em 2005, o Dia Mundial da Usabilidade contou com a participação de 34 países, atraindo mais de 10.000 participantes nos locais e outros milhares via on-line. Esta é a terceira edição do evento no Rio de Janeiro e segundo o organizador e Doutor em Design, Robson Santos, a expectativa é fazer com que as pessoas percebam a importância da usabilidade.

    “As palestras tem como público-alvo o consumidor, que muitas vezes se sente frustrado diante da dificuldade de usar produtos e serviços que adquire. E se estendem também a empresários e profissionais das áreas de comunicação, informática, design e qualidade, responsáveis na produção destes produtos e serviços.”

    Manero hein Dulça

    Bom, desculpem o formato meio que “sério demais” que não tem muito meu estilo. Mas estava sem saco tempo para criar um post sobre o evento e achei que esse trecho se encaixa bem pelo que o evento vai mostrar.

    Data e local

    Vai ser nessa quinta agora, dia 13 de novembro de 2008 (óbvio), às 17h30 e com previsão para terminar às 21h30.

    E o local será o Teatro da Cidade, na Univer Cidade, campus Ipanema (que fica em frente à Lagoa, mas é considerado Ipanema ainda). E que fica nesse endereço modafoca: Avenida Epitácio Pessoa, 1.664. E a entrada é gratuita. 😉

    Inscrições e mais informações sobre o evento

    Banner do WUD 2008

    Se inscreva pelo site mesmo, coisa rápida. Pode ser clicando no banner acima 😉 . E veja mais informações no site do evento.

    Mais informações sobre o evento

    O responsável mor é o grande modafoca e meu camarada, Robson Santos, D.Sc. ESPM-Rio, Univer Cidade.

    E a programação do evento você pode conferir abaixo ou então vendo no eflyer do evento:

    17h30 – Boas vindas e Abertura – Robson Santos, D.Sc.

    17h40 – Casos e experiências

    • Projeto de aeronaves – Saulo Hideki (Designer, RJ)
    • Acessibilidade no transporte público carioca – Everaldo Bechara (Centro de Treinamento iLearn, RJ)
    • Projetos para transporte ferroviário – Bruno Batela (Designer, RJ)
    • Metodologias de usabilidade web – Letícia Cianconi (Especialista em usabilidade – Tesla, SP)

    18h40 – Intervalo

    19h – Palestras

    • GPS, mapas e mobilidade – Daniel Rocha (Fórum Nokia)
    • TEX – Solução para o caos no trânsito – Dan Strougo (Indio da Costa Design, RJ)

    20h – Mesa redonda

    • Para onde vai o transporte do Rio? Perspectivas em usabilidade nos transportes

    21h30 – Encerramento

    Finalizando

    O tema não me atrai tanto assim, mas eu vou comparecer para ver as idéias e propostas, que devem ser interessantes. Nos vemos por lá. Aquele abraço.

    [ 10/nov/2008 às 18:22hrs ] [ Por Bruno Dulcetti ] Comentários 2 Comentários |

    Categorias: Eventos,Usabilidade

    » Até onde vai o limite da Semântica?

    E ae pessoal. Tempo que não posto sobre web standards, css e afins, que são os temas principais desse Blog. Muitos trabalhos, pouco tempo, meio “sem saco” para escrever (blogueiros são humanos também sabiam?) 😛

    Tá blz Bruno, mas isso todos dizem. Vá direto ao ponto…

    Ok, ok… Não estou aqui para falar de trabalho, dar desculpas sobre minha falta de tempo e “saco” sobre postagens no blog, etc. Estou aqui para falar de um assunto que tenho certeza que já passou na cabeça de praticamente todos os desenvolvedores web, que trabalham com webstandards.

    Semântica… A velha e temida semântica…

    Não falarei sobre semântica web, citarei alguns exemplos para vocês entenderem e depois os casos reais para que vocês entendam porque estou escrevendo este post ok?

    Beleza então Bruno cite os exemplos.

    Todos sabemos que as tags <hn> são as tags de título (onde n é o número que varia de 1 a 6), sabemos também que a tag <a> é para links, <p> serve para parágrafos, etc, etc, etc.

    Sabemos que temos tags que são display block e display inline correto? Não sabemos? Okay, explicarei um bocado sobre:

    Display Block

    Traduzindo, são blocos. Os elementos blocks adicionam uma quebra de linha antes e depois dele próprio. Seria como se tivesse um <br /> antes e depois da tag. Podem conter tanto elementos inlines quanto blocks dentro dele.

    Alguns Exemplos:
    • <p>
    • <h1>
    • <div>

    Display Inline

    Ao contrário do block, os elementos inlines não quebram linha. Podem conter outros elementos inlines dentro dele próprio, mas não é permitida a inserção de elementos do tipo block dentro deles.

    Alguns Exemplos:
    • <a>
    • <strong>
    • <em>

    Resumindo…

    Veremos alguns exemplos da forma correta e da forma não-correta de se utilizar elementos inlines e blocks:

    Modo correto

    <p>Aqui vem o <a href="#">meu link com <em>Itálico</em></a></p>

    Resultado

    Aqui vem o meu link com Itálico

    Como no meu css está configurado para os links ficarem em negrito, acabou ficando tudo em negrito onde tem o link ok?

    Neste exemplo podemos ver que temos o parágrafo, que é block, e dentro dele temos um link, que é inline, que dentro dele temos um em q dá ênfase ao termo entre esta tag.

    Resumindo, temos inline dentro de inline, que estão dentro de um bloco, tudo certinho.

    Modo incorreto

    <a href="#">
    <h1>Aqui vem o título</h1>
    <p>Aqui vem o parágrafo</p>
    </a>

    Resultado

    Como o resultado irá invalidar o código, podendo deixar uma bagunça, criei uma página só pra esse exemplo.

    Agora iremos ao ponto chave desse post.

    Vimos que esse segundo exemplo está errado, pois o link, que é um elemento inline, contém elementos blocks (h1 e p). Percebam que MESMO declarando no css o display: block pra link, ele, por padrão na W3C, é inline, portanto é descartado o CSS, ou seja, não é validado pela W3C.

    Beleza Bruno, mas o que podemos fazer?

    Temos uma opção, que seria englobar o h1 e o p dentro de uma div e coloca um link dentro do h1 e outro, com o mesmo href, dentro do p. Veremos neste exemplo.

    Agora sim, ele ficou validado pela W3C, porém, podemos ver dois pontos, o primeiro é que o link não ficou englobado totalmente na div, somente quando passa em cima do texto e a o segundo ponto é que temos que colocar o link duas vezes, com o mesmo endereço e isso pode aumentar de acordo com os elementos dentro dessa div.

    Verdade Bruno… Mas não tem nenhuma opção de conseguirmos validando na W3C?

    Até temos uma opção, que criei aqui agora, mas seria bem do tipo POG.

    Vamos ver o código HTML:
    <div>
    <a href="#"> </a>
    <h1>Aqui vem o título</h1>
    <p>Aqui vem o parágrafo</p>
    </div>

    Aqui, nada demais. Uma div com um link, um título e um texto de parágrafo. A única diferença é no link, que está vazio e por cima de todos. Vamos entender, vendo o código CSS:
    div {
    width: 140px;
    border: 1px solid #900;
    background-color: #E4E5E5;
    position: relative;
    overflow: hidden;
    }

    a {
    display: block;
    width: 1000px;
    height: 1000px;
    position: absolute;
    background-color: #E4E5E5;
    filter: alpha(opacity=0);
    opacity: .0;
    }

    h1, p { font: 12px Verdana; }

    Não entrarei em detalhes na lista de propriedades para a div, pois é bem básica. A única coisa diferente é que coloquei um position relative, porque irei usar dentro dela um bloco com position absolute. Coloquei também um overflow hidden, isso quer dizer que se algum conteúdo ultrapassar o tamanho da div, ele ficará oculto, sem atrapalhar em nada o layout da págin e da div.

    No título h1 e no parágrafo, só coloquei o tipo e tamanho de fonte, nada demais nisso ok?

    Agora que “o bicho pega” :D. No link que a brincadeira começa a ganhar forma e tudo começa a ficar mais fácil de ser entendido.

    O link recebe um display block, com isso, vira um bloco. Mas lembram que ele esta acima do link e do parágrafo, pois ele é inline e não pode englobar blocos?

    OBS: Não importa que você tenha setado no CSS que o link virou bloco, a W3C continuará não validando seu código, pois ela confere com o padrão dos links, e como o <a> é um elemento inline como padrão, não validará. 😉

    Não se assustem com os 1000px para a largura e a altura do link, pois como a div está com overflow hidden, o link só aparecerá dentro do tamanho disposto na div ;). Na verdade um 100% na altura e largura já funciona, mas no ie 6 não funcionou, aconteceu algum bug, ficando só pela metade, vai entender né… 😉

    Legal Bruno, mas o título e o parágrafo desceriam…

    Sim, mas como temos o position absolute, isso não acontece mais. Ele fica grudado na div e o conteúdo que vem depois dele, fica aparecendo também, o link fica por cima deles.

    Só isso? Mas tem mais código lá ué!

    Sim, eu sei. Na verdade, nosso problema teria sido resolvido, mas não podemos esquecer, temos que nos preocupar com o ie. Somente com aquele código, no ie 6 fica ruim, não funcionando totalmente, com o link somente em algumas partes da div.

    Mas isso é resolvido colocando uma cor de background no link, porém, teremos um link por cima de tudo, com uma cor sólida por cima. Ganhamos um problema. Temos um link na div toda, mas como tem uma cor de background, não vemos o conteúdo por trás.

    Mas temos soluções (gambiarras?) para tudo. 😀 Temos uma propriedade no css, a filter, que só funciona no ie. Os valores variam dentro dessa propriedade, podemos colocar opacidade, blur, glow, entre outras coisas que não ficarei aqui citando.

    No nosso caso, precisamos da opacidade, por isso, coloquei o seguinte valor:
    filter: alpha(opacity=0);

    Nesse caso, alpha modifica a opacidade do elemento, que nesse caso é o nosso link. Setei um valor 0 (zero), que significa que quero totalmente transparente. O valor varia de 0 (transparente) até 100 (totalmente visível).

    Mas só resolvemos o problema do ie, conseguimos deixar o link transparente no ie, falta no Firefox também. Mas precisamos só de mais uma propriedade, a opacity, que recebendo 0 (zero), fica totalmente transparente.

    Ufa. Que saco hein Bruno

    Nem me fale isso. É um saco isso tudo, mas conseguimos chegar no resultado final.

    Lembrando que, esse macete não funciona no Opera. Não tenho Opera aqui instalado, por isso não posso confirmar, mas tenho quase certeza que não funciona, ou seja, não é muito legal utilizá-lo :D.

    Voltaaaaaaaaaando ao foco do Post…

    Acabei escrevendo até um pequeno tutorial, mas tudo bem né :D. Acabei saindo do foco do assunto do post.

    Mas voltando ao assunto dele, chegamos no ponto crucial. Vimos aqui que temos soluções para esse probleminha mostrado por mim aqui, mas vimos que é meio chato fazer e não muito funcional, pois como eu disse, não é certo de funcionar no Opera.

    Vale a pena focar a semântica SEMPRE? Ou melhor, vale a pena focar a Validação na W3C?

    Esse é o ponto principal do Post. Em relação a semântica, temos dois lados:

    • Link englobando o título e o parágrafo como um bloco, ficando invalidado na W3C, pois o título seria um h1 e o parágrafo um p;
    • Link englobando um strong e um span, sendo eles o título e o texto do parágrafo do texto, ficando assim, validado, pois é tudo inline.

    Na primeira opção, temos um link englobando tudo e o título sendo título e a descrição sendo um parágrafo, tudo correto, mas como o link é inline, não é validado.

    Na segunda, temos o link englobando tudo e um strong sendo o título e um span sendo a descrição. Passa no validador, mas no olhar semântico, nem tanto.

    É aí que entra a discussão, será que vale MESMO fazer tudo para validar na W3C? Mesmo que para isso você perca a semântica, as vantagens de se utilizar um h1, h2, h3, entre outros? Vale mesmo deixar tudo inline para validar? Será?

    Já vi posts sobre isso, como o do Henrique do Revolução etc, tem outro do Tableless chamado Validar é importante?!, etc.

    Eu acho importante validar na W3C Bruno. Por que você não acha?

    Não ponha palavras na minha boca (ou seria letras nas minhas teclas?), eu só estou dizendo que existem casos e casos. Você pode muito bem ter um site que ao invés de usar h2, utiliza um <p class=”titulo”>, existe o caso de você esquecer de fechar uma tag, etc, etc, etc.

    O caso que citei, foi um caso que está tudo certo, a única coisa “errada” é a utilização do link envolta do título e do parágrafo. Nosso código está semântico, está correto, a não ser pela W3C não permitir links, por serem inline, englobarem blocos.

    Como aqui na Globo o pessoal preza a validação na W3C (pelo menos tentar ao máximo), eles utilizam spans e mais spans dentro de links para não ficar errado na W3C.

    Eu acho que, neste caso, possa dar uma “esquecida” na W3C e colocarmos o link, não vejo mal algum nisso, está tudo funcionando, tudo certo, só a “bendita” W3C falando que meu código está incorreto. Eu não acho e aí? Como que fica isso? 😀

    Mas, isso varia de pessoas e pessoas e eu estou aqui para saber a opinião de cada um que lê este blog, para ver se eu estou viajando, se só eu que penso assim, ou tem desenvolvedores que pensam assim, mas nem sempre agem assim por causa dos seus trabalhos ;).

    Resumindo

    Na verdade, o que eu acho é que a W3C deveria criar uma nova tag, chamada <ablock>, que seria um link também, mas como um bloco, com isso, não precisaríamos nos preocupar com isso não é verdade? Ou melhor, fazer com que consultasse o CSS e visse “se o <a> é um bloco, então valido, senão não valido”, o que seria melhor ainda, pois não seria necessário a espera de novas versões dos browsers, que por parte do FF, Opera seria tranquilo, mas o ie… aff…

    Finalizando…

    E você? O que acha disso? Acha certo “pular a cerca” da validação da W3C nesse caso? Ou você faz parte do grupo “Validação acima de tudo”?

    Deixe sua opinião 😉

    Aquele abraço.

    [BBL]acessibilidade, artigos, css, globo, html, semantica, usabilidade, validacao, w3c, web-standards, webstandards, xhtml[/BBL]

    [ 30/nov/2006 às 17:27hrs ] [ Por Bruno Dulcetti ] Comentários 8 Comentários |

    Categorias: Acessibilidade,Artigos,CSS,Usabilidade,Webstandards

    » Backoffices precisam ser webstandards?

    Estava eu aqui, produzindo, quando de repente me veio essa pergunta na cabeça… Primeiro, para os que não conhecem o termo, Backoffice é o mesmo que o sistema criado para um site, os famosos CMS‘s da vida. Quando você cria um site, vocês tem pelo menos duas opções de atualização de conteúdo de um site: ou você pega o html (ou qualquer arquivo de qualquer linguagem) e coloca este conteúdo, tanto texto, quanto imagens e sobe de novo via FTP. É um modo meio chato, mais trabalhoso e temos também o modo via Backoffice ou CMS, que onde o usuário fica responsável pelo conteúdo exposto no site, sem a necessidade do criador do site fazer a atualização.

    Hoje, acho primordial a utilização dos padrões web na criação de um website. Site dividido por camadas estrutura / estética / funcionalidade, validado pela W3C, tanto html/xhtml quanto css para evitar erros de nomeação, entre outros, fora a rapidez, economia de tempo tanto na criação quanto mudanças e outras inúmeras vantagens que todos aqui devem saber.

    Mas será que vale a pena deixar o Backoffice deste site dentro dos padrões, pelo menos a risca? Antigamente eu fazia o Back via tabela, como só o cliente vai ver, não teria problema, mas depois, com mais amadurecimento dentro dos padrões, percebi que era importante a utilização dos padrões no Backoffice.

    No início, quando ainda nem utilizava o Firefox direito, eu criava os backoffices pro i.e., pois achava que todo mundo utilizava-o, ninguém iria barrá-lo (aff, como pensei nisso ¬¬), criava o backoffice somente pro i.e. e depois quando comecei a descobrir o Firefox, que via a bagunça que ficava, pensei comigo “E se meu cliente começar a utilizá-lo? To ferrado!”. Exatamente isso. Mas depois, coloquei minha cabeça no lugar (ou será que foi a W3C, W3Schools, Tableless, arqHP e afins? :P), comecei a criar como padrão dentro de todos os browsers que tinha acesso.

    Daí pensei comigo: “Pronto, perfeito”, mas depois via que tinham alguns erros no código, entre outros via validador W3C.

    Com isso, veio essa pergunta que foi lhes apresentada no título deste post: “Será que os Backoffices precisam ser webstandards?” Logicamente eu respondo para vocês, mas depois pergunto de novo: “Mas será que precisam seguir tanto a risca? Será que precisamos perder um pouco do tempo precioso nos preocupando com alguns erros dentro de uma área que somente o cliente irá ver? E que o cliente nem vai ter noção que tem erro, somente o validador mesmo?

    Toco em outro ponto, sempre, sites, principalmente portais tem um público-alvo, portais então, com uma variedade imensa. Pessoas com deficiência, pouca coordenação motora, não enxergam muito bem, entre outras coisas. É muito importante investir na usabilidade e acessibilidade nesta hora para tentar agradar ao máximo de pessoas possível. Aí entro no Backoffice mais uma vez, será que vale manter uma regra de usabilidade / acessibilidade rígida para um backoffice? O número de administradores chega a três no máximo por exemplo, com toda aptidão e sem nenhuma dificuldade, aí novamente a pergunta: “Neste caso valeria a pena investir um tempo nesta parte?”, ou você preferiria deixar como está e se por acaso um deles ficar cego, sofrer um acidente grave, você viria com um novo orçamento, dizendo que iria deixá-lo perfeito na acessibilidade?

    Foi apenas um pensamento que pensei em dividir aqui no Blog, para se alguém quiser postar opiniões, críticas, e tudo mais, falar aqui mesmo.

    Eu acho que os Backoffices tem que ser webstandards sim, mas não creio que com tanta perfeição quanto ao site mostrado ao cliente. Seu público alvo é um só algumas vezes, podendo aumentar, mas com um número muito baixo. Acessibilidade? Sim, é uma ótima, mas valeria a pena “labiar” com o cliente sobre tal assunto e tentar colocar algo a mais, pois daria um trabalho. Mas tomem cuidado no argumento, senão o cliente vai pensar que você está de urucubaca pra cima dele, pra ele ficar cego e precisar de sites totalmente acessíveis 😀

    Tirando as brincadeiras, termino aqui. Participe se quiser, espero que seja útil, de repente alguém já tenha pensado nisso. 😉

    Aquele abraço.

    [ 27/jan/2006 às 23:00hrs ] [ Por Bruno Dulcetti ] Comentários 5 Comentários |

    Categorias: Tecnologia,Usabilidade,Webstandards

    » Pesquisa Usabilidoido

    Falae pessoal, o Fred do Usabilidoido lançou sua segunda pesquisa, quarta-feira dia 11, com seus leitores do Blog, para contar suas http://www.usabilidoido.com.br/segunda_pesquisa_com_nossos_leitores.htmlopiniões sobre o site.

    Não gastei mais de um minuto para participar da pesquisa e estou aqui para indicá-la. Vale o clique com certeza, aliás, nós mesmos que ganharemos com isso não é verdade?

    Parabéns so Fred pelo blog, que hoje é um dos mais visitados do Brasil sobre usabilidade.

    Segunda pesquisa com nossos leitores.

    Aquele abraço.

    [ 13/jan/2006 às 10:33hrs ] [ Por Bruno Dulcetti ] Comentários 1 Comentário |

    Categorias: Tecnologia,Usabilidade

    
    Copyright © 2005 Bruno Dulcetti | Creative Commons
    Bruno Dulcetti atuante na área de desenvolvimento web / webdesign e colaborador na área de webstandards pelo Blog BrunoDulcetti.com - blog. Atuante na área desde 2000. Atuando na cidade de Niterói/RJ - Brasil. E-mail: bruno@brunodulcetti.com