Etiqueta: webdev

WordPress, ‘titles’, ‘alts’ y ‘captions’…

La interfaz de WordPress avisa que usará el mismo texto para la 'leyenda' de la imagen
¿Debe usarse la 'leyenda' como 'texto alternativo'?

…o títulos, leyendas y textos alternativos, si somos más respetuosos con el idioma. Cuenta WordPress desde hace un tiempo con una interfaz ‘muy apañá’ para subir imágenes a nuestras entradas. Y aún así, cada vez que la uso la maldigo un poco… Y es que esa insistencia en usar un único campo para leyenda (o pie de foto) y texto alternativo de una imagen es bastante contraproducente.

  • Dice el W3C que el atributo title puede anotar diversos elementos (entre ellos, los a y los img). Los agentes de usuario visuales (también conocidos como navegadores) los pueden mostrar, por ejemplo, como «tool tips» si nos paramos con el ratón sobre el elemento en cuestión, mientras que los auditivos (los lectores de pantalla) podrían leer en voz alta el contenido del atributo al pasar por él. Aunque solo es una sugerencia.
  • También cuenta el W3C que el atributo alt debe especificarse para los elementos img y area (y es opcional en input y applet). El atributo da un texto alternativo a la imagen (o applet o…) a usar cuando el agente de usuario no puede mostrarla (como es el caso con los lectores de pantalla o los dispositivos que transforman texto en braille). Para hacernos una idea, si nos estuviesen «contando la página por teléfono» sería lo que querríamos que nos dijesen al llegar a la imagen.
  • Finalmente, según el DRAE, entre otras cosas la leyenda es el texto que acompaña a un plano, a un grabado, a un cuadro, etc. Vamos, el texto que ponen bajo la foto los diarios…

Uno entiende que WordPress exija un ‘título’ para las imágenes: de alguna forma hay que guardarlas en la base de datos. No entiende tanto que coloque ese título como elemento title de las imágenes por defecto y sin preguntar. Pero directamente no le cuadra nada que texto alternativo y leyenda sean una misma cosa: en la mayoría de casos nadie pondría como leyenda la descripción del contenido de la imagen. Cuando el blogger poco familiarizado con temas de accesibilidad (¿podemos suponer que la inmensa mayoría?) sube una imagen, piensa en el pie de imagen… y acaba castigando al que debe usar un lector de pantalla con un texto duplicado y que, de regalo, le deja en muchos casos sin la más remota idea de qué hay en la imagen. Para los que nos preocupamos algo más del tema (no tanto como deberíamos, pero lo tenemos en mente), la herramienta nos obliga luego a buscar en la entrada y poner las cosas como corresponde, haciéndonos perder un minuto innecesariamente. WordPress, además, presume de su atención a los estándares web o sea que, aprovechando que se acerca verisón nueva, ¿por qué no darle un repaso al tema?

Adobe a por el mercado móvil con Distributable Player y Mobile Packager

Adobe sigue posicionándose en el mercado de herramientas de desarrollo de aplicaciones para móviles y otros dispositivos «no convencionales». Esta vez se trata de un par de anuncios:

  • Por un lado, el Adobe Mobile Packager, una aplicación de escritorio (aún en prerelease) que permite empaquetar archivos SWF, un comprobador de versiones de Flash Player, un icono y metadatos para dispositivos con sistemas operativos Symbian o Windows Mobile, de manera que el proceso de instalación de aplicaciones sea el ‘de toda la vida’ para esas plataformas.
  • Por el otro, el Flash Lite 3.1 Distributable Player que es, precisamente, eso: un ‘runtime’ redistribuible que podemos empaquetar con nuestras aplicaciones de forma que podemos obviar la necesidad de que el móvil del cliente tenga instalado Flash Player, pagando el cada vez menor precio de aumentar el peso del paquete a distribuir e instalar.

El objetivo, obvio, comprensible y previsible, de Adobe, es disponer de una plataforma equivalente a Air, pero para móviles: toda la autoría y programación con herramientas de Adobe y un proceso de ‘write once, package many times’. Esto hace cada vez más atractiva la ‘plataforma Flash’ (esto es, Flash y Flex y aditamentos como el futuro Flash Catalyst (el artista anteriormente conocido como Thermo)) para el desarrollo de aplicaciones conectadas y/o sincronizables y ricas en contenido multimedia, generado, cómo no, con las otras herramientas de la casa: Photoshop, Premiere, After Effects…

No es seguro que la apuesta funcione, por múltiples motivos…

  • El primero, que hay que convencer a los desarrolladores «clásicos» que las herramientas de Adobe son válidas. Flex ya lleva unas cuantas iteraciones y cosas como el uso de Eclipse como entorno de desarrollo deberían ayudar, pero hay una mucha inercia contra la que luchar.
  • La competencia no es manca: cierto es que Silverlight de momento no es más que una mota de polvo en la pantalla del radar, pero obviar los esfuerzos de Microsoft en un campo tan jugoso equivaldría al suicidio. Los de Redmond, además, aunque ‘no existen’ en el campo, cuentan con la inercia de una masa innumerable de desarrolladores muy acostumbrados a sus herramientas, a los que Microsoft seguirá tratando con el esmero habitual de la casa.
  • En los dispositivos móviles, les falta la joya de la corona, el iPhone. De momento el ‘pique’ de Apple contra Adobe y la no inclusión de un Flash Player en el smartphone que ha roto todas las barreras de adopción tiene que estar doliendo mucho por San Francisco. De todas formas, parece que Adobe ya tiene desarrolladísimo su Flash Player para iPhone y eso significa, con los nuevos anuncios, que solo necesitan añadir un empaquetador que escupa código para iPhone (y iPod Touch) y colar unas cuantas aplicaciones (esto último igual les cuesta más…) para ser también una herramienta viable en el mundo de ‘tito Estif’.

Si les sale, puede ser la carambola de la década, al menos: una única suite capaz de producir todos los recursos y escupirlos para, a todos los efectos prácticos, todas las plataformas del mercado: Windows, Mac, Linux, la web, Symbian, Windows Mobile y iPhones y familia…

Más información para desarrolladores. Vía.

Una de estadísticas y ancho de banda

Cómo acceder a las estadísticas con Dreamhost y WordPress

De interés para los que tengáis un blog WordPress con Dreamhost. Pero también aplicable a todos los ‘hosts’ que albergan estadísticas en URIs del estilo http://tu.domin.io/stats. Como WordPress modifica el archivo .htaccess, esas estadísticas dejan de funcionar. Para volver a poder acceder a ellas, basta con modificar el .htaccess y, antes del código generado por WordPress, añadir

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . - [L]
</IfModule>

Todas las estadísticas son importantes

Hay dos tipos de estadísticas para sitios web: las que se generan a partir de una mosca de JavaScript (como Extreme Tracking o Google Analytics, que son las que usamos en obm y las que se obtienen a partir de los registros del servidor web (en Dreamhost utilizan una herramienta llamada Analog). Pues bien, todas son importantes. A pesar de que la potencia de las moscas es difícil de superar, hay cosas que se les escapan.

¿Que por qué lo digo? Porque hacía semanas que pensaba en arreglar el .htaccess para poder acceder a las estadísticas de Analog en Dreamhost… y una vez hecho, me llevo la sorpresa de que obm, más que un blog, es una emisora de radio hiperespecializada. En serio. Os cuento. Hace un par de años, a la muerte de Syd Barrett, colgué un par de emepetreses de Pink Floyd. En algún momento, esos dos emepetreses fueron indexados por unos cuantos buscadores especializados. Resultado: en octubre respondimos a unas 180,000 peticiones de Wish You Were Here y 17,000 de Shine On You Crazy Diamond. Resultado: 4 de cada 5 bytes servidos en octubre desde obm corresponden a esos dos emepetreses. Casi nada. Y si bien (i) no me parece mal haber colgado esos archivos en su momento y mantenerlos en el contexto de la entrada, mientras ninguna parte interesada me pida que los retire y (ii) me sobra el ancho de banda, no me parece bien ese ‘hotlinking’ masivo. Por lo que…

Cómo evitar el ‘deeplinking’

Fácil. Basta volver a editar el .htaccess y, también antes del código generado por WordPress, añadir

RewriteEngine on
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?obm.corcoles.net/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?corcoles.net/.*$ [NC]
RewriteRule \.(mp3)$ - [F]

obm.corcoles.net y corcoles.net serán, a partir de la edición, los únicos sitios desde los que se podrán cargar los archivos con extensión mp3.

De nada…

Blogs obesos

Dicen que el primer paso para resolver un problema es reconocerlo. Y parece ser que en TechCrunch se han dado cuenta del brutal problema de obesidad web que les afecta: enlazan a Royal Pingdom, que ha hecho un análisis de pesos de los blogs del ‘top 100’ de Technorati y la cosa es que como para hacer saltar todas las alarmas: un peso medio de 934 kBs, con hasta 35 de los 100 que pasan del mega.

Para apreciar la magnitud de la tragedia, pensemos en las «tarifas iPhone» de Movistar España: la de 15 euros al mes da para apenas 7 páginas vistas al día si no queremos agotar la velocidad 3G, mientras que con la de 25 euros llegamos a la impresionante cifra de 35 páginas diarias… Una vez agotada esa cuota, no quiero pensar la gran experiencia que puede suponer cargar TechCrunch, con su peso por encima del mega…

Las cosas no van mucho mejor por estos lados de la web. La página sobre Safari para el iPhone pesa algo más de 500 kBs, ElPaís.com está en 700, la de LaVanguardia.es (anuncio de llegada incluido) pasa de de 2 megas, elmundo.es está en 750… Mirando el top 10 de Alianzo para España, lo de los blogs, afortunadamente, está algo mejor, pero tampoco es de premio: unos muy razonables 250 kBs para los Microsiervos, 800 para Genbeta, Enrique Dans está en los 400 y pico, google.dirson en 300, Barrapunto y Escolar se llevan premio por no llegar a 200, Error 500 pasa de los 450, Kirai se lleva el premio al «gordo del día» con 6 megas (cierto es que tiene un buen montón de fotos… y que está acostumbrado al ancho de banda japonés), Mangas Verdes está en los 400 y Vida Extra se va a 2 megas… (obm estaba antes de publicar esta entrada por los 120, pero también tiene sus momentos de obesidad, o sea que mejor no nos colgamos medallas).

Digo yo que, en estos tiempos de web móvil y multidispositivo, igual no estaría mal vigilar un poco más la báscula…

Un Spectrum on-line… ¡en JavaScript!

Un emulador de Spectrum corriendo en el navegador
Im presionante

En serio. No, no es Java. Ni Flash. Es JavaScript. Y consume recursos que da gusto, desde luego, pero es que… es JavaScript. Dónde iremos a parar. No tengo palabras. ¿Se podrá ser más geek? Y yo que creía que el récord insuperable lo habían establecido AC/DC… La fuente. Vayan y háganle la ola, por favor…