tecnologías web – Página 2

Paypal caido, ¿por el fallo de seguridad?

Hace unos días, the Inquirer hacía eco de un exploit en la seguridad del sitio de paypal, y hoy (a las 19:15 GMT+1), justo cuando me disponia a realizar el pago online de una licencia de software, me encuentro con esto:

Por lo que leí, el fallo en su pasarela permitía lanzar una ejecución en su site con código javascript malicioso, el cual podría permitir el desvio de datos (por ejemplo credenciales de autenticación) a otros servidores de internet.

Supongo que las pérdidas en transacciones para miles de compras solo las puede justificar la corroboración de dicho problema, y que estén trabajando en ello.

Un fallo de seguridad así es terrible, y más en un sistema de pagos con tanta difusion como paypal. Paypal siempre ha presumido de invertir ampliamente en la seguridad de sus sistemas, pero parece que no ha sido suficiente. ¿O simplemente es que la seguridad total es inalcanzable?.

Mi compra tendrá que esperar…

Marketing en Internet (Iniciador mayo 2008)

Como mes a mes, siempre que podemos nos pasamos por el evento Iniciador, esta vez dedicado al márketing en internet, de la mano de Ismael El-Qudsi, director de Nuevos Servicios en Havas Digital.

Tras una definición de qué es esto del márketing (ofrecer un producto destinado a satisfacer una necesidad), nos habló de las 4 P del márketing: Producto (incluyendo empaquetamiento, post-venta, etc..), Precio (ajustado a cada nicho), Place (lugar) donde vendes tu producto, Promoción.

Sobre el producto, enfatizó en su diseño, que para tener éxito siempre debe ser accesible, usable, y si permite feedback mejor aún, todo esto nos permitirá no perder usuarios en el camino. Sobre la distribución en internet nos habló de medios como la publicidad tradicional (banners, enlaces, etc), el SEO , el SEM y el SMO.
SEO: Muchos os preguntaréis ¿Por qué es importante el SEO? o incluso ¿Qué es el SEO? . La importancia del mismo viene de que la mayor parte de la gente no suele pasar de la primera o segunda páginas de los resultados de búsqueda y otra la podéis hayar en El poder de la F.

SEM: Es el diseño de los anuncios pagados, es fundamental que llame la atención del usuario incitándole a visitar nuestra web, y que una vez en ella ni se pierda por la falta de usabilidad, ni salga despaborido por la cantidad de datos innecesarios que le solicitamos.

SMO: Social Media Optimization, presencia en sitios sociales, envío de noticias, vídeos, etc, pero sin ser “pesado”.

También nos habla de que es importante escuchar qué se dice de nosotros, de forma manual o mediante herramientas (en Havas Digital utilizan herramientas propias basadas en las Apis de Tecnorati), algo que me recuerda a las empresas dedicadas al escrutinio de la prensa escrita en busca de comentarios o noticias acerca de sus clientes.

Su ponencia termina tratando la importancia de la opinión de los usuarios hoy en día, el poder del branding (tener una marca que todos recordemos), y de la utilidad del márketing viral y de guerrilla.

Aunque es un tema que daría para largo si lo tratásemos en detalle Ismael obsequió con una síntesis del tema bastante interesante para todos los no iniciados en esto del “internet marketing”.

Adobe AIR y FLEX 3 : Live Demos

DISCLAIMER: Este post es una copia del publicado en Maestros del Web por mi (la segunda parte).

Probablemente lo más impresionante del evento de la semana pasada fueron las demos de productos construidos con AIR. Tuve la oportunidad de escuchar una presentación similar el año pasado en el Future of Web Applications en Londres, sin embargo no hubo tiempo para ver todas las demos. Esta vez si las pude ver de cerca y en más de una ocasión me hicieron exclamar un “WOW” ante las virguerías que se pueden hacer con la tecnología.

Lo primero que me llamó la atención es que Adobe mantiene un mercado en donde va colgando para su descargas todas las aplicaciones implementadas con AIR de las empresas que se las mandan. Primero se las somete a un exhaustivo análisis y si lo pasan se certifican y se añaden a la web de Adobe para su descarga. Esto proporciona tanto a Adobe como a los desarrolladores y empresas de las aplicaciones, una publicidad estupenda y que animo a muchos a aprovechar.

Analytics Report Suite

Esta aplicación realizada por Nico, un desarrollador Belga, nos trae todos los datos de Google Analytics al escritorio. No solo permite visualizar los datos con gráficos adicionales a los de la web, sino que además permite exportar los datos en varios formatos (pdf, xml, etc.).

Ebay

Ebay ha realizado un cliente para permitir la compra/venta de objetos de sus subastas desde el escritorio. El interfaz no tiene absolutamente que ver con la web y me atrevería a decir que es mucho más limpio y práctico. Realmente esta aplicación es la evolución lógica de la barra de herramientas que hicieron para navegadores hace ya un tiempo. Si con ese plugin consiguieron aumentar el tráfico en la web por 10, no me quiero imaginar lo que puede pasar con esta aplicación en AIR.

Top100videos

Un aplicación desarrollada por AOL para visualizar los 100 vídeos musicales más populares del momento desde nuestro escritorio. El interfaz es muy bonito y permite encontrar información no solo del vídeo sino del grupo/cantante y comprar el álbum online. Muchos de los vídeos están restringidos mediante geolocalización de forma que solo funcionan en EEUU. Esto mismo pasa con otros websites como Last.fm o Pandora.com. Una lástima la verdad.

Finetune

Esta fue una de las demos que más me gustó y que más dudas me generó simultáneamente. La aplicación permite reproducir las playlists de nuestra música en finetune pero desde el escritorio. Adicionalmente a esto, permite cargar y reproducir también playlist locales que tengamos en el ordenador. El sistema cargará la lista y se descargará desde Internet la información relevante (título, álbum, artista, etc.) de la canción. Por un lado esto está genial, pero por otro lado da un poco de miedo que la aplicación pueda acceder a información local y la envíe remotamente. Se me ocurren un par de asociaciones y compañías que matarían por tener esa información en su poder.

Pownce

Como no podía faltar, una aplicación AIR para recibir y enviar mensajes en Pownce. Tiene un aire muy similar a Twitterrific pero para Pownce. Por mucho que me guste Twitter, no se si este tipo de aplicaciones son saludables en pro de la procrastinación. Lo cierto es que el feeling de la aplicación es muy bueno y según comentó Mike, solo le llevo al desarrollador un par de semanas, teniendo en cuenta que jamás había trabajado con Flex.

Para colofón, nos hizo una demo de como construir un navegador en Flex con el Flex Builder en 5 minutos que, al menos a mi, me dejó atónito. Nunca había visto el Flex Builder (nunca he desarrollado nada en Flex, de ahí que no lo conociera) y he de reconocer que me impactó mucho la facilidad con la que se pueden hacer aplicaciones muy chulas. Ya existe una beta para Linux así que lo probaré dentro de poco y ya escribiré mis impresiones.

Finalmente Mike comentó que estaban trabajando para incluir soporte P2P en el próximo release de AIR, incluso comentó sucintamente que también estaban experimentando con añadir soporte para VoIP en un futuro. En mi opinión y, a falta de haber probado Silverlight de Microsoft, he de reconocer que AIR me tiene cautivado y que no veo el momento en que saquen la beta para Linux para poder trastear con ello. Creo que es una tecnología que va a dar mucho que hablar y que va a generar una explosión de aplicaciones web (híbridas) para el escritorio dado que facilita enormemente el desarrollo de estas.

Imágenes: cnet.com, desarrolloweb.com, popeater.com, bornontheweb.be, adobe.com

Adobe AIR y FLEX 3 : Presentación en Madrid

DISCLAIMER: Este post es una copia del publicado en Maestros del Web por mi ayer.

La semana pasada se presentaba en Madrid la plataforma para Rich Internet Applications (RIA) de Adobe. Esta presentación es consecuencia del release de la versión 1.0 de Adobe AIR (Adobe Integrated Runtime) y FLEX 3 la semana pasada en EEUU. Adobe AIR es un entorno de ejecución que permite a los desarrolladores, emplear tecnologías web para la construcción de aplicaciones que se ejecuten en el escritorio, sin necesidad de un navegador. Flex es un entorno de desarrollo open source que permite la construcción y mantenimiento de aplicaciones web para su uso en todos los navegadores.

La presentación inicial corrió a cargo de Miguel Bada, Director de Marketing de Abobe Ibérica. Puso de manifiesto cifras y datos sobre la compañía y sobre como ha ido innovando a lo largo de sus años; primero fue Postscript, luego Photoshop, Acrobat Reader, Flash y por último Air.

Entre los datos interesantes sobre la compañía cabría destacar los porcentajes de uso de los productos de Adobe. La tecnología Flash está presente en el 98% de los ordenadores del mundo, esto representa unos 3400 millones de instalaciones. Estas cifras lo convierten en el software más extendido del mundo. Por otro lado, el Acrobat Reader está presente en casi el 100% de los ordenadores del mundo. Hoy por hoy Flex lleva ya 560.000 descargas, que no son pocas teniendo en cuenta que Flex está orientado a desarrolladores exclusivamente.

Tras la introducción corporativa tomó las riendas a Mike Downey, platform evangelist de Adobe. Mike se incorporó a Macromedia en 2000 que fue absorbida por Adobe en 2005. Durante ese tiempo Mike fue Senior Product Manager de Flash hasta que en diciembre de 2006 pasó a formar parte del equipo de AIR.

Adobe AIR es una tecnología multiplataforma, es decir, que una aplicación funcionará tanto en Windows como en Mac OS X (Linux también en unos meses) y sin tener que cambiar el código. Esto es una gran ventaja para los desarrolladores. Lo curioso es que Java, en teoría ya es multiplataforma, sin embargo y como puntualiza Mike, existen diversas implementaciones de la maquina virtual de Java, cada una distinta y que evitan que las aplicaciones sean realmente multiplataforma. AIR, al provenir de un mismo fabricante, no tiene ese problema. El instalador es además universal, un solo fichero para todos los sistemas operativos, siendo realmente multiplataforma. Sin embargo, yo me pregunto, ¿qué pasará cuando exista en el mercado distintas versiones de AIR? ¿Mantendrá esta compatibilidad entre distintas versiones?

Uno de los puntos que más me ha gustado, ha sido la explicación del lo que hay debajo de AIR. Los chicos de Adobe han integrado el motor de renderizado WebKit que emplea Safari, junto con el motor de renderizado Flash. Pero no solo eso, sino que al estar ambos motores integrados, se permite llamar a la API de uno desde el otro. Por ejemplo, con AIR podremos llamar a funciones de la API de Flash desde una función en Javascript. No hace falta decir que esto es un gran avance en cuanto a tecnología web se refiere.

Además de la integración de estos dos motores, AIR proporciona una capa de abstracción adicional con varias APIs que no están disponibles desde un navegador:

Acceso a la API del sistema de ficheros local
Detección de la red (si el equipo está online u offline)
Funcionalidad para hacer Drag and Drop desde el escritorio
Notificaciones
API para controlar la actualización remota de la aplicación
Acceso a una base de datos local (Basada en SQLite)

Adicionalmente AIR tiene soporte para distintos codecs de audio y vídeo de última generación como H.264 o HE-AAC (Soporte de audio de alta eficacia) y su máquina virtual es una de las primeras implementaciones del estándar ECMAScript versión 4 que existen. Estas características le dan a AIR una ventaja técnica considerable porque ya incluye las tecnologías y estándares del futuro, haciéndolo una opción muy atractiva si se desea mantener y actualizar una aplicación durante un largo período de tiempo.

Por último agradecerle a Adobe la invitación y a todas las personas que hicieron posible el evento. Nos vemos el día 31 de marzo en el rally On AIR Europe.

Comprimir el código Javascript

Las aplicaciones web cada vez son más complejas. Cada vez se requiere más código Javascript que permita obtener la funcionalidad deseada. Debido a esta necesidad, y al igual que sucedió con las librerías en los sistemas operativos, han ido surgiendo varias librerías de código Javascript. Estas, además de descargar al programador de codificar tediosas rutinas para el acceso al DOM y similares, proporcionan una capa de abstracción que permite la portabilidad del código a distintos navegadores. Para los profanos, explico la situación. Hoy por hoy existen diversos navegadores web, siendo probablemente el Firefox, Internet Explorer, Safari y Opera los más importantes. Cada uno de estos navegadores implementa el motor de renderizado web de forma distinta. Algunos de ellos se ciñen a los estándares oficiales, mientras que otros deciden introducir sus propios elementos xhtml, html, etc al margen del resto. Esto genera graves problemas de interoperabilidad para las páginas web. Un diseño que emplea ciertos elementos CSS, es probable que no funcione como se deseaba al visualizar la misma página en otro navegador. Existe una problemática adicional, cada navegador luego tiene sus múltiples versiones que soportan subconjuntos diferentes de los estándares, agravando los problemas de interoperabilidad.

Las librerías Javascript proporcionan una capa de abstracción para el programador y le evita tener que programar distintas versiones del mismo código para los distintos navegadores. Dos de las más famosas probablemente sean la librería jQuery y Prototype. Sin embargo, a diferencia de las librerías de un sistema operativo, éstas otras han de ser descargadas (si no han sido cacheadas, lo que sucede el 50% de las veces) por cada usuario que visualice la web. Esto supone un problema de rendimiento, ya que el navegador no comenzará a hacer uso del código Javascript hasta que este haya sido descargado. Cuanto mayor es el tamaño de la librería, peor es el rendimiento.

Para evitar estos problemas de rendimiento, voy a introduciros una herramienta desarrollada por Yahoo para reducir considerablemente el tamaño de estas librerías y maximizar la velocidad de carga de la web. La herramienta, que se llama YUI Compressor es una aplicación Java (jar) a la que le damos el fichero Javascript de entrada y nos devuelve por la salida estándar una versión comprimida de la misma. A continuación os muestro las prueba que he realizado con la última versión de jQuery:

ergosum@braniac:/var/www/js$ ls -la jquery-copy-1.2.2.js
-rw-r–r– 1 ergosum ergosum 95285 feb 8 16:49 jquery-copy-1.2.2.js

ergosum@braniac:/var/www/js$ java -jar yuicompressor-2.3.4.jar jquery-copy-1.2.2.js > jquery-compress-1.2.2.js

ergosum@braniac:/var/www/js$ ls -la jquery-compress-1.2.2.js
-rw-r–r– 1 ergosum ergosum 52435 feb 8 16:51 jquery-compress-1.2.2.js

Como podemos apreciar, al comprimir la librería hemos obtenido una tasa de compresión del 45%, lo cual es increíble. El problema con el algoritmo de compresión es que convierte la librería en algo bastante ilegible. Si deseamos reducir el tamaño del código pero al mismo tiempo mantener algo de coherencia y no ofuscarlo, podemos lanzar la herramienta como sigue:

ergosum@braniac:/var/www/js$ java -jar yuicompressor-2.3.4.jar –nomunge –preserve-semi jquery-copy-1.2.2.js > jquery-compress-1.2.2.js

ergosum@braniac:/var/www/js$ ls -la jquery-compress-1.2.2.js
-rw-r–r– 1 ergosum ergosum 52970 feb 8 17:21 jquery-compress-1.2.2.js

Podemos comprobar la opción para añadirle los puntos y comas el tamaño ha incrementado ligeramente (44.41% de compresión). Sin embargo he de reconocer que no sale mucho más legible que antes. También podemos añadirle el parámetro –line-break n indicándole al parser que debe añadir un retorno de carro cuando llegue a la línea n. Esto lo hace algo más legible pero no mucho más.

Como nota adicional, leía ayer los resultados que han obtenido la gente de PBWiki (muy interesante por cierto) con distintas herramientas para el rendimiento de las librerías. Para jQuery obtuvieron los siguientes datos:

Minified	Time Avg	Samples
minified	519.7214	12611
packed	591.6636	12606
normal	645.4818	12589

Donde minified corresponde a la salida comprimida mediante la herramienta que hemos comentado, packed corresponde con librerías comprimidas con el empaquetados Packed y por último normal corresponde con la librería tal cual, sin procesar.

Se aprecia claramente como la minified es más óptima que la packed y la razón es porque, aunque con Packed el tamaño del fichero es menor, es necesario realizar un esfuerzo extra para desempaquetar el fichero una vez que llega al navegador, resultando en una suma total de tiempo mayor que en el caso del minified.

En conclusión, una herramienta muy útil que nos permite minimizar el tiempo de carga de nuestras librerías Javascript. Además de la compresión también podemos usar recursos como el mod_gzip para comprimir el archivo desde el servidor a nuestro navegador y seguir ganando en eficiencia.

html head, y el posicionamiento web.

En los últimos post sobre posicinamiento web hemos tratado temas como el formato de las url , la elección de un nombre de dominio. Esta vez vamos a hablar sobre las cabeceras de nuestras páginas, y la relevancia de los campos que estas contienen, ya que de ahí los buscadores obtienen gran parte de la información sobre el contenido de la misma.

Prácticamente como el sentido común nos indicaría el orden de importancia para las partes de la cabecera HTML en el que la mayor parte de expertos están de acuerdo (Seomoz: Google search engine ranking factors) es el siguiente:

<title>: Es el más importante por dos razones: Es el título que aparece en las búsquedas (ver la imagen del final) y las palabras clave de su contenido son muy relevantes para las búsquedas. No solo es importante su contenido, si no el orden de las palabras clave: si están al principio es probable que adquieran más relevancia que si están al final. Si forman un conjunto, y están en están en el orden adecuado (en el que serán buscadas) esto también nos beneficiará. Por ejemplo, será mas óptimo un título: “html head y el posicionamiento web – tecnocracia.es” que … “tecnocracia.es – html head y el posicionamiento web” ya que en este caso lo más relevante del título no es “tecnocracia.es”, sino el título del tema en si.
<meta name=”description” content=”…”/>: No es tan importante como el título, pero puede aportar algo más de relevancia, y actualmente es el contenido que aparecerá en la descripciones del buscador (ver imagen del final).
<meta name=”keywords” content=”key1,key2,key3″/>: Es el menos importante de todos los campos de la cabecera HTML, en algún momento de la historia de los buscadores se les dio gran relevancia, pero es algo fácil de manipular por los spammers, y hoy en día intuyo que se puedan utilizar para extraer el orden de relevancia de las palabras clave que estén en el contenido.

En resumen podemos decir que la correcta optimización de las cabeceras de nuestras páginas de contenido es fundamental si queremos atraer visitas. Además el contenido de las cabeceras es la primera ventana que tienen los usuarios hacia nuestra web, lo que verán de ella antes de llegar a entrar, y como todos sabemos la primera impresión cuenta mucho 🙂

Nombre de dominio para posicionamiento web.

En el último post sobre posicionamiento web tratamos el tema de las URL, unas URL bien construidas pueden ayudarnos con los resultados de las búsquedas. Como alguien nos apuntó en la introducción: el nombre de dominio puede jugar un factor importante.

Algo que es bastante lógico, pero que puede pasarnos desapercibido, es que si nuestro nombre de dominio tiene las palabras clave en cuyas búsquedas nos interesa aparecer tendremos mucha relevancia para las mismas:

Ejemplos

He subrayado en rojo los resultados que encajan en el nombre de dominio y en azul los que encajan en la URL.

foro empresa: en google.es

búsqueda de “foro empresa” en google

foro empresa: en yahoo.es

Búsqueda “foro empresa” en yahoo

Estos ejemplos están sin marcar, pero se pueden ver claramente, ya que los buscadores a dia de hoy resaltan las palabras clave en los resultados:

casa rural: en google.es y en yahoo.es
feria: en google.es y en yahoo.es

Según vamos avanzando en las páginas de búsqueda vemos como esa concentración de las palabras clave en el dominio y la URL se diluye. Esto nos muestra la preferencia que los buscadores asignan a las páginas cuyos dominios y URLs contienen las palabras clave buscadas, y es mayor esta relevancia si el orden de estas palabras clave es el mismo que se utilizó para buscar.

Conclusión

Debemos recordar que este es uno más de los factores que influyen en la relevancia de una página frente a ciertas palabras clave, y probablemente no es uno de los más importantes. En las búsquedas de ejemplo se puede observar claramente que el título de la página es otro de esos factores.

Podemos decir, que a la hora de escoger un nombre de dominio para un sitio web puede ser interesante seleccionar uno que contenga las palabras clave mas relacionadas con el contenido que va a tener. A veces esto no es nada sencillo, y en esos casos mi opción suele ser la búsqueda de un nombre corto, fácil de recordar, y que suene bien. En casos como el nombre de una organización, lo más normal es que las palabras claves más relevantes sean el nombre de la propia organización., o sus siglas

Ladrones de nombres

El principal activo de una startup tecnológica es su dominio web. Nombres como apple.com, google.com o facebook.com nos son muy familiares a todos. Sin embargo, el camino hasta dar con el dominio perfecto para la empresa no es nada fácil. Hace años, cuando Internet no era más que cuatro nodos gestionados por entidades académicas, conseguir un dominio era mucho más fácil.

Hoy es muy complicado encontrar un dominio que, por un lado esté acorde con el nombre de la empresa, y por otro esté libre y sea fácil de pronunciar, deletrear y recordar. Para cualquier startup que se precie, este proceso es de obligado cumplimiento y muchas veces muy crítico. Es por ello que cuando todavía no se tiene un dominio, el emprendedor tiende a evitar comentar el nombre de su empresa por si alguien se lo roba.

Debido a ésto, el proceso de registrar un dominio debe mantenerse en secreto y realizarse con mucho cuidado. ¿Por qué digo esto? Pues porque últimamente hay informes de que existen ciertas filtraciones en el proceso de registrado de dominios y algunas empresas se están beneficiando de ello. El marco es el siguiente, el interesado realiza una búsqueda de un dominio, comprueba que no existe, pero cuando al día siguiente va a registrarlo descubre, para su desgracia, que otra empresa ya lo ha registrado a las pocas horas de su consulta el día anterior.

¿Cómo ha sucedido esto? Esto se puede deber a muchas circunstancias que expondremos a continuación. ICANN, el máximo organismo de gestión de Internet, ha emitido una nota (pdf) de aviso sobre estos problemas, que ellos llaman Domain name front running.

Existen varias posibles razones para que nuestra consulta haya sido interceptada, almacenada y vendida a terceros. Entre las más comunes son las siguientes:

Usar la barra de direcciones del navegador para comprobar si un dominio existe. Muchos usuarios consideran que si al teclear el dominio en el navegador, sale una página web es que el dominio no está libre. Nada más alejado de la realidad y sobre todo peligroso. Cuando realizamos esta operación, nuestro ordenador está preguntando al servidor DNS de nuestro proveedor si existe el dominio. Algunos proveedores de Internet (ISPs) almacenan estos datos y venden la información de aquellos dominios que se han buscado pero que no existían. De esta forma, en cuestión de horas, estas terceras empresas registran los dominios, con la esperanza de que si realmente te interesa, les pagarás bastante dinero por el. A parte de esto comentar que, el hecho de que no salga una página web no significa que el dominio esté libre.
Usar buscadores de tercera división para comprobar si un dominio existe. Por buscadores de tercera me refiero a cualquier buscador que no sea Google, Yahoo o similares (ask.com por ejemplo). Esto es debido a que estas empresas tienen unas políticas de privacidad muy importantes y, en teoría, no van a vender esta información a terceros. Por el contrario, si usamos buscadores dudosos o muy poco conocidos, tenemos muchas probabilidades de que nuestras búsquedas se almacenen y vendan a empresas que se dedican a buscar nuevos dominios.
Usar plugins para el navegador o programas gratuitos o de shareware. Existen infinidad de programas que podemos descargarnos y que proporcionan herramientas para gestionar y/o consultar dominios. Mucho cuidado con ellas ya que algunas almacenan la información para luego venderla.
Usar portales de entidades no oficiales para consultar los dominios. Un claro ejemplo de este comportamiento es el de Network Solutions y su “mecanismo de protección“. Parece ser que si realizas una búsqueda a través de su portal en Internet, el dominio se registrará automáticamente por ellos durante 4 días.

El gran problema con el protocolo DNS es que se envía en claro por el cable. Cuando digo en claro me refiero a que se transmite la información de la consulta sin cifrar, permitiendo su interceptación y almacenamiento. Si tenemos en cuenta que esa consulta pasa por numerosos routers y servidores hasta llegar a su destino, tenemos un escenario muy peligroso. Lo ideal sería que las consultas whois estuvieran cifradas, sin embargo, el costo computacional de tener que cifrar todas las peticiones dns hace de esta solución algo prohibitivo.

En conclusión, mucho cuidado con que sistema usáis para consultar los dominios y cuidado con los proveedores que venden vuestros datos. Espero que este pequeño articulo les evite a muchos (yo me incluyo) el perder nombres de dominio (con lo que encima cuesta pensarlos) por una tontería.

formato de las URL para posicionamiento web.

Como comentamos en el artículo de introducción al posicionamiento web uno de los parámetros que pueden aportar mejoras tanto al posicionamiento, como a la accesibilidad de nuestras páginas es un buen formato para las URL, preferiblemente estático.

Las URLs en una página web con contenido dinámico suelen tener el siguiente formato:

http://www.empresas.es/directorio/listado.php?id=123&tipo=consultoria&sesion=aazhdjje4543234534534dde

Rompiendo en partes la URL anterior tenemos:

http:// – protocolo http, y separador
www.empresas.es – subdominio (www), nombre de dominio (empresas), tipo/país del dominio (.es)
/directorio/ – ruta dentro del servidor.
listado.php– aplicación encargada de atender la petición.
? – separador para el conjunto de parámetros de la URL.
id=123– primer parámerto, en este caso le está indicando a la aplicación el identificador de la entrada dentro de la base de datos.
&– separador de parámetros
tipo=consultoria – indica a la aplicación que dicha entrada pertenece a la categoría de las consultoras y que debe buscarla en la tabla de consultoría.
& – separador de parámetros
sesion=aazhdjje4543234534534dde – identifica la sesión del usuario actual (esto podría haberse hecho con una cookie, por ejemplo)

Es sencillo observar, que de esta URL, un buscador podría obtener algo de información acerca de la jerarquía de los datos (se encuentran dentro de la carpeta /directorio/) y que pertenecen a la categoría de “consultoría”.

Cambiando el formato de la URL podríamos aportar más información, por ejemplo añadiendo el nombre de la empresa en la URL, y haciendo un árbol de categorías, así cada una de las categorías quedaría “hospedada” dentro de /directorio/, conteniendo a su vez las distintas empresas. Eliminar el identificador de sesión utilizando cookies para ello (cuando sea posible) quitará ruido de nuestra URL, aunque cuando un identificador es muy largo algunos buscadores lo interpretan como un identificador de sesión y lo eliminan automáticamente de sus bases de datos.

Suponiendo que la empresa con identificador 123 en nuestra base de datos se llamase “Jimenez y Asociados”, la URL inicial después de la optimización propuesta quedaría así:

http://www.empresas.es/directorio/consultoria/jimenez-y-asociados-consultores-123.html

Notad además el 123, que se ha añadido al final de la url, de forma que la aplicación web en vez de tener que buscar a la empresa por el nombre lo podrá hacer directamente por el identificador de la base de datos. Esto suele ser una buena estrategia, ya que ahorramos tiempo de proceso: las búsquedas son mas rápidas, y además evitamos problemas en los casos en que el título es el mismo.

Si utilizamos el servidor web apache, un método extendido y simple es la utilización del módulo Rewrite, gracias al cual solo tendremos que preocuparnos de construir las urls de la forma deseada en nuestra aplicación, dejando la interpretación y traducción al propio mod_rewrite por medio de expresiones regulares.

Para el ejemplo anterior utilizaríamos una configuración así en nuestro servidor o en el .htaccess de nuestro hosting:

RewriteEngine on
RewriteBase /
RewriteRule ^directorio/(.*)/(.*)-(.*).html$ /directorio/listado.php?id=$3&tipo=$1 [L]

# Para depurar es interesante
RewriteLog /ruta/rewrite.log
RewriteLogLevel 2

Una entrada del log accediendo a la url del ejemplo quedaría algo parecido a esto:

87.218.47.80 - - [03/Jan/2008:16:36:02 +0100]

rewrite 'directorio/consultoria/jimenez-y-asociados-consultores-123.html'

->

'/directorio/listado.php?id=123&tipo=consultoria'

Aquí os dejamos algunas referencias interesantes:

El poder de la F

Una de las preguntas que los emprendedores nos hacemos más frecuentemente es, ¿cómo he de diseñar mi página web para maximizar las visitas? Como muchas personas ya saben, un buen diseño es, por norma general, una de las bases del éxito. Es por ello que, identificar los hábitos de lectura de las páginas web es muy valioso. Esto es lo que hizo hace ya tiempo Jakob Nielsen mediante el uso de mapas de calor. Llevó a cabo un experimento en donde analizó los lugares donde los usuarios fijaban la vista al leer una página web. Con esos datos elaboró un mapa de calor, en donde las zonas que más se leen aparecen en rojo y las que menos en azul.

El experimento demostró que, gran parte de los lectores leen las páginas web formando una “F”. Los usuarios leen primero en horizontal, las primeras líneas de texto de la web. A continuación pasan a leer las segundas líneas, pero esta vez el recorrido horizontal es menor al anterior. Por último, los usuarios pasan a leer el resto del texto en vertical, prestando solo atención a las 2 ó 3 primeras palabras de cada línea.

Evidentemente esto no se cumple siempre, pero se pueden extraer poderosas conclusiones. Aunque el artículo data del 2006, quiero comentarlo porque he vivido este efecto recientemente. Después de leer el artículo, hace ya un tiempo, decidí probar algún sistema que me permitiera crear mapas de calor de mis webs. Encontré uno, crazyegg, que, aunque solo permite realizar un seguimiento de los clicks, proporciona suficiente información para obtener conclusiones importantes. Las conclusiones fueron sorprendentes. Sucedía efectivamente un fenómeno de “F”, donde los enlaces de la primera y segunda línea horizontal eran los que más clicks recibían. Como muestra la imagen siguiente, la “F” no es tan clara como en los experimentos del Dr. Nielsen, pero si se aprecia un patrón bastante similar.

Debido a que muchas páginas web se sustentan gracias a los anuncios, es muy importante saber cuales son las zonas más leidas de una página. Por ello recomiendo a los interesados, que se pasen por la web del Dr. Nielsen, en donde encontrareis numerosos artículos (en inglés), sobre distintos fenómenos de la lectura de páginas web.

Imágenes: useit.com, crazyegg.com