Archivos Usabilidad: Diciembre 2007
Este post estaba en borrador, y ahora lo completé como respuesta a una pregunta de FT via twitter,
Si algún día TinyURL o Dev.cl dejan de prestar servicio... ¿mueren todas las URLs cortas creadas?
La respuesta corta es Sí.
Incidentalmente, cuando traté de acortar la url de este post dev.cl me devolvio la url http://dev.cl/.
Ahora la respuesta entretenida:
Aunque las urls cortas tienen varias aplicaciones y ventajas, incluso sirven para comprimir imágenes ;) la verdad es que hay varios problemas:
Jeff Atwood resume varios de estos problemas:
- Si el servicio desaparece, las urls quedan rotas para siempre. Tal como teme FT.
- El otro problema es la calidad del servicio, efectivamente un servicio de este tipo que funcione esporádicamente (con "apagones") puede ser una situación aún peor.
- Se pierde la cualquier pista sobre el contenido de la url, al ser todas esta homogéneas, y estar resumidas en un codigo críptico. Esto es malo para la experiencia usuario del que está haciendo click en el enlace.
- Hay servicios de redireccionamiento de urls que han sido usados en formas cuestionables, por ejemplo spammers (fue el caso de lnk.to).
Otros problemas que Atwood no identifica son:
- La redirección introduce latencia.
- No es bueno usar esto para cosas como ajax, o web services.
- Si tu firewall o proxy reverso bloquea el servicio lo hace inutilizable
- El servicio puede estar lleno de basura, como urls que ya no estan vigentes, al perder la pista no te enteras hasta que haces el click.
- Si una url falla no sabes si es el servicio de compresion el que falló o si la url original la que tiene problemas.
- Tinyurl no maneja bien algunas "urls extrañas" con caracteres como la coma (',').
A pesar de esto, las urls cortas son útiles en diversos contextos, como lo demuestra su uso en twitter, o para enviarlas en emails, o en mensajes SMS.
¿Por qué Google no provee este servicio?
Esa es una buena pregunta, y como dice Atwood, probablemente esto le daría mayor seguridad al servicio.
A lo mejor han analizado el problema y no ven el negocio para este servicio, o no quieren complicarse con el problema de los spammers.
Aunque sospecho que no quieren ponerse en una situación tan incomodamente hegemónica.
Una alternativa sería descentralizar el servicio, una especie de P2P de urls cortas, una idea que no he explorado, pero puede ser interesante.
(Lo que sí he explorado es la idea de eliminar el DNS, pero eso quedará para otro post.)
Quizás un análisis interesante sería ver que pasa con estos servicios y el principio de que las urls cools no cambian.
En primera instancia uno pensaría que al agregar un nivel de indirección esto servicios pueden ayudar a preservar este principio, pero si observamos con mayor detención, en realidad complican más el problema.
Efectivamente, si la url inicial cambia, además hay que propagar ese cambio a todas las urls cortas de todos los servicios de este tipo.
Ahora bien, el problema de la persistencia de las URLs es más complejo aún, y la caida de servicios tipo tinyurl es sólo una clase de los problemas asociados a la persistencia de las URLs.
** ¿Cómo implementar un servicio como este? **
Ahora, para finalizar, déjenme criticar la propuesta de Atwood de usar hash como mecanismo para generar URLs cortas.
Aunque a primera vista parece bueno (algoritmo O(1)), no parece la forma más práctica para implementar este servicio. Los hashes que muestra generan strings mucho más largos que los que observamos en estos servicios.
Mejor optar por un algoritmo O(N log (N)) como el siguiente:
- Existe una tabla URL, indexado por ID y URL_LARGA
- Se recibe una url y se busca por URL_LARGA obteniendo ID o NULL.
- Si se obtiene NULL se inserta un nuevo elemento en la tabla y la URL corta sera la raiz del sitio mas el ID expresado en base 64.
Que nos permite generar urls bastante cortas, y es facil de implementar.
No creo que sea fácil encontrar una función hash que genere strings más cortos que los que genera este algoritmo.
Como Tip adicional, en vez de realizar la redirección usando PHP, o Python, yo optaría por escribir un modulo apache en C, o en PERL, esto aceleraría en al menos un orden de magnitud el servicio (si es que no más). O quizás creando mi propio servidor web. Y por último, trataría de mantener la tabla en memoria, o al menos un caché de las URLs más visitadas.
Hace rato que TinyUrl venia molestando por su insistencia en hacer campaña política.
Ahora hay una alternativa chilena, gracias a Carlos Fuentealba, se trata del sitio dev.cl.
Funciona perfectamente con Twitter, y es mas corto que una url en TinyURL.
Para los que son del pasado, este servicio permite acortar una URL grandota (como http://www.channel4.com/entertainment/tv/microsites/I/itcrowd/) en una mas pequeñita como (http://dev.cl/vj1c).
Si no saben que es una URL, bueno, ¿que hacen leyendo esto?
¡Buen trabajo Carlos!
Les quiero presentar un par de innovaciones del investigador Johnny Chung Lee, postulante a doctorado en la Universidad de Carnegie Mellon.
La primera innovación la descubrí a través de un post en
Botón Turbo.. Lamentablemente en ese blog no entendieron muy bien que es lo que sucede, así que permitanme explicarlo, antes de presentarles el video.
En este caso Chung Lee escribe un programa en C# y utiliza el control de la Wii como dispositivo de entrada conectado a su Laptop, corriendo Windows. En ningún momento ha escrito código que se ejecute en la consola de Nintendo, todo ocurre en el laptop, y lo que se usa es el WiiMote. La característica principal de esta innovación es que utiliza el control de la Wii al revés, mueve el sensor infrarrojo en vez del WiiMote.
Noten el efecto que se produce al introducir el marco, una técnica usada en computación gráfica. Claro que sólo sirve para un usuario, el que esté portando el sensor infrarrojo a la altura de sus ojos. Como explica Chung Lee, esta innovación le da nuevas posibilidades a la Wii.
La segunda innovación de Chung Lee, y que a mí me parece más interesante es cómo usa este concepto de usar el WiiMote para seguir el rastro de un lapiz infrarrojo. Con esto monta una pizarra interactiva, y luego construye su propia versión del Surface, claro que a una centésima parte del costo (una WiiMote cuesta unos 50 dolares, y un Surface unos 5000).
¡¡Con esto se pueden montar pizarras interactivas en cualquier colegio, a una fracción del costo!!
Lo mejor es que todo el código fuente de estos proyectos está publicado, les sugiero explorar la página de proyectos de Chung Lee y sorprenderse con este innovador.
Estos proyectos han sido desarrollados en Windows usando como base la Managed Library for Nintendo's Wiimote escrita por Brian Peek y publicada en el blog de Microsoft Coding4Fun.
Recibí un comentario en mi post Un Laptop por Gato, creo que es interesante destacarlo, porque por es un testimonio de como están percibiendo en Uruguay este proyecto:
ACLARACION:
1. Creo que he cometido un error al publicar este comentario de manera destacada, con esto solo he alimentado a los trolls.
2. No es la percepción de Uruguay, sólo la de una persona: Alejandro Lavarello, y ese es mi segundo error, dada la redacción original.
Por lo tanto, he decidido dar un nivel de indirección al comentario, y deberán leerlo donde fue publicado por su autor.
Gracias FT, porque su comentario me hizo reflexionar (lo que demuestra que hay que siempre aprender de los profesionales). Antes de publicar, hay que revisar las fuentes.
Bruce Schneier sintentiza en una frase esa frustración que se siente cuando los usuarios no comprenden que hay cosas que simplemente no se pueden hacer (o no tienen la solución simple que ellos esperan).
"I feel rather like the physicist who just explained relativity to a group of would-be interstellar travelers, only to be asked, 'How do you expect us to get to the stars, then?'"
"Me siento como el físico que ha terminado de explicarle la relatividad a un grupo de futuros viajeros interestelares,para que luego le preguntes, ¿cómo espera que lleguemos a las estrellas entonces?"
Todo esto a propósito de por qué las listas negras no funcionan, ¡no lo sabré yo!.
Les sugiero implementar un sistema de chat que filtre "frases inapropiadas" y van a entender a que me refiero.
