Alpha's Manifesto

A black and white figure's thought-hive

¿Confianza del usuario vs. URLs acortadas?

Desmintiendo si las URLs acortadas afectan o no la confianza del usuario

Hoy voy a dejar un caso de una pregunta abierta, nuevamente, originada en los foros de User Experience. La pregunta es: ¿Los usuarios confían en URLs acortadas?

Siempre se supo, y es un concepto fundamenta del SEO, que las URLs deben ser lo suficientemente amigables como para significar algo que sea relevante al contenido de ese recurso. Por otro lado, la teoría debajo de REST y la web semántica nos indican que las URLs (o URIs) deberían ser identificadores únicos de un recurso en particular, de forma que, de alguna manera, su identificador tendría cierta relación con su contenido.

Sin embargo, y aún así, parece no haber estudios definitivos realizados sobre lo que los usuarios en general opinan. Nosotros hemos experimentado confianza o desconfianza de estas URLs dependiendo de quién vienen, o en dónde las encontramos. Básicamente, dependería del contexto.

Sin embargo, ninguna de las respuestas tiene algún estudio que demuestre la fiabilidad de su fuente, por lo que yo ya comencé una pregunta que pide por ellos, pero veremos qué ocurre. Esta pregunta sigue abierta e invito a los lectores a aportar cualquier información que tengan al respecto.

Soy un zorrinito acortado.

¿Por qué distintos dominios para recursos estáticos?

La razón detrás de las URLs raras...

Sabemos que el nombre no es más que un nombre y que no importa cuál sea el servidor actual en donde se están alojando los datos, pero parecería que es una práctica común de muchos sitios grandes (léase: Facebook, Twitter, Google, etc.) hacer referencia a muchos de sus recursos en dominios externos. Por ejemplo, las imágenes de Facebook se encuentran alojadas debajo de http://static.ak.fbcdn.net/ y no debajo de http://www.facebook.com/, ni siquiera debajo de http://imgs.facebook.com/. ¿Por qué?

Alguien ya hizo esa pregunta y la respuesta fue nueva para mí: hay una limitación en varios browsers (y hastas donde yo sabía, algunos sistemas operativos) que previene hacer más de dos, tres o cuatro conexiones simultáneas a un mismo hostname. De hecho, es parte de la especificación HTTP 1.1 (parece que cumplir el estándar no siempre está tan bueno, ¿no?). Ahora, si notaron, la limitación es por hostname, ¿por qué entonces utilizar distintos dominios? La razón es evitar cookies que pueden estar yendo y volviendo en cada uno de los pedidos, y para evitar eso, se puede usar un dominio extra que nunca devuelva cookies. De esa forma, sitios grandes como estos se ahorran mucho bandwidth.

UPDATE: Gracias a Exos, que claramente estaba más informado que yo en este tema, las limitaciones exactas son de tres conexiones por cada dominio y cinco para cada IP. Los distintos dominios/subdominios ayudan a utilizar CDNs para distribución de contenido con mayor velocidad. Exos está en desacuerdo (y demuestra por qué, miren los comentarios) con que las cookies sean una gran carga respecto del bandwidth. Entonces el por qué de los dominios vs. subdominios queda en duda, pero suponemos que debe estar relacionado con políticas de administración interna de cada empresa.

Soy un zorrinito performante.

Link del día: Cómo diseñar URLs

El diseño de URLs es lo que primero se ve de una aplicación web. Es prácticamente nuestro punto de entrada a la misma, y de alguna forma nuestro mapa mental del sitio fuera del sitio.

Gracias a un tweet de @Xyborg y de @Woork me enteré de un artículo de Kyle Neath llamado URL Design en donde aborda el tema. Por suerte no es una consideración general sino que toca muchos puntos interesantes, como por ejemplo, de qué forma plantear determinadas jerarquías, de qué forma presentar una dirección si se trata de la misma información que ya se ve o de nueva información, como trabajar con el historial y las nuevas funciones de HTML5, etc.

Pero lo más importante es que nos provee un criterio muy interesante sobre la forma en que las URLs deben ser construidas para representar algo fácil de recordar y algo representativo de la información.

Como extra y relacionado, que también me pareció muy interesante, es la forma en que se debe planear para evitar conflictos de URLs entre contenido de usuario y funcionalidades que actualmente no existen en el sistema. ¿Cómo planear a futuro? Acá está la pregunta: How do sites prevent vanity URLs from colliding with future features? Las respuestas son más que curiosas.

Soy un zorrinito universal.