Categoría: Media doscero

Los acortadores de URLs son malos, t.co es el peor…

Los que estéis acostumbrados a Twitter estaréis cansados de ver que muchos de los enlaces que corren por allí tienen una cierta tendencia a ser de la forma bit.ly/algo, ow.ly/lootro, goo.gl/lodemasalla, o similares…

Los acortadores tienen un par de razones de ser:

  1. Cuando el espacio es limitado (y 140 caracteres son muy limitados), una URL como http://obm.corcoles.net/20110901/los-acortadores-de-urls-son-malos-t-co-es-el-peor, con sus 82 caracteres, es un bozal, básicamente. Si puedo dejarlo en los 18 caracteres de http://j.mp/q9pmvn, paso de disponer de 58 caracteres para el resto del tuit a más de 120. El doble. Nada desdeñable.
  2. A todos (o no, pero al menos a mí sí, y no creo que sea único :-P) nos gusta saber qué pasa con nuestros enlaces. Pero medir quién hace clic en una URL es, básicamente, imposible… a no ser que uno use un acortador (hay otros métodos, pero todos comparten la filosofía): cada vez que alguien hace clic en un enlace de bit.ly, éste se interpone muy brevemente entre el usuario y su destino (del orden de 1 o 2 décimas de segundo) y toma nota de ese clic (y, en la medida de lo posible de otros datos ‘demográficos’, como el origen geográfico del clic). Ello me permite saber, por ejemplo, que en los últimos 30 días se han hecho unos tristes 750 clics en mis ‘enlaces bitly’.

Pero a cambio, los acortadores, como avanzaba en el título, son malos (aunque poco, en general): al interponerse entre el usuario y su destino frenan (muy poco, ciertamente) la navegación; además, añaden un posible punto de fallo extra a cada enlace: si bit.ly se cae, alguien que intente seguir mis enlaces lo va a tener más bien complicado para hacerlo. Además, suponen un riesgo añadido para el usuario: si haces clic en http://j.mp/q9pmvn no sabes dónde vas. Y eso no suele ser una buena idea (hoy en día, una web maliciosa puede hacer mucho daño). Queda el hecho de que el dominio .ly corresponde a Libia, un país en guerra y con una situación legal poco estable, y que «el» gobierno libio podría decidir mañana que el servicio de bit.ly no se ajusta a su legalidad e interrumpirlo sine die, inutilizando los muchos enlaces que he publicado usándolo. Alguien podría hackear el servicio, además, y reenviar a todo el mundo a donde le diera la real gana

A pesar de esos puntos negativos, yo, como usuario informado (no mucho, pero más que la inmensa mayoría, me temo), decido voluntariamente usarlo, después de pesar pros y contras.

¿Por qué es peor t.co, pues?

Los pecados específicos de t.co son actuar sin necesidad ni permiso y mentir. Véase este tuit, por ejemplo:

Tuit de @jimgroom, retuiteado por @brianlamb. el tuit contiene un enlace a shenandoahliterary.org
¿Enlaza eso a donde parece?

Ese tuit (el programa de la captura de pantalla es Tweetdeck, que, curiosamente, es propiedad de Twitter) sólo enlaza a shenandoahliterary.org en apariencia: de hecho, es un enlace a http://t.co/r70nSBy, que a su vez redirige a donde deberíamos llegar en primer lugar. A pesar de que Jim no quería acortar la URL, que el tuit cabía en 140 aún sin acortar (de hecho, t.co alarga algunas URLs (las j.mp, por ejemplo)), que hace unos días no habría pasado y que nadie de Twitter ha avisado a sus usuarios de que iba a pasar.

(No es Twitter la única empresa que hace esto: si buscas ‘otro blog más’ en Google y haces clic en el primer resultado, a pesar de que lo pueda parecer, estarás haciendo clic en una URL de la forma http://www.google.com/url?sa=t&source=web&cd=1&ved=0...A&url=http%3A%2F%2Fobm.corcoles.net%2F&rct=j&q=otro%20blog%20m%C3%A1s&ei=A...N&usg=A...Q&sig2=D...Tg&cad=rja, de forma que Google puede tomar nota de que has hecho clic en ese enlace después de la búsqueda, lo que les permite, por un lado, mejorar el funcionamiento del buscador y, por otro, aprender más sobre ti para poder colocarte mejor publicidad y ganar más dinero. Prácticamente igual de malo, pero al menos no han modificado un mensaje mío sin mi permiso.)

¿Un gran crimen?

Desde luego, no es lo peor que se ha hecho en la web últimamente ni de lejos (me recordaban mientras escribía esto lo de Google y la recopilación ‘accidental’ de los SSIDs de las WiFis por parte de los coches de Maps…). Pero si me parece que entorpecer la navegación y modificar mis mensajes sin mi permiso es, cuando menos, de pésima educación.

Google+ da ‘circles’, yo quería ‘channels’. Creo

Que sí, que Google+ acierta en que el futuro de las redes sociales es asímetrico (esto es, estilo Twitter, no Facebook: que tú me sigas a mí no implica que yo te quiera seguir a ti). Pero me da a mí que (al menos de momento, que la cosa está muy verde y en desarrollo) han perdido la oportunidad de implementar la simetría por el lado que a mí me gustaría.

Me explico: de momento Google+ me permite seguir a quien yo quiera, por un lado y, por el otro, colocar a la gente en ‘circles’ para elegir yo con quien quiero compartir lo que publico por allí. Si creo que a Pepe le van a interesar mucho muchísimo los clips de vídeo que me gustan a mí, meto a Pepe en el círculo de los clips de vídeo. Y Pepe se ‘come’ los clips, le gusten o no (hasta que se harte y me bloquee, momento en el que se perderá los enlaces sobre apicultura, que sí le gustan).

Los ‘circles’ están bien como concepto, desde luego: quiero tener un ‘círculo de amigotes’ para quedar para el viernes por la noche, por ejemplo, y un ‘círculo de compañeros de trabajo’ con fines mucho más aburridos pero igualmente útiles.

Pero echo de menos (como ya echaba de menos en Twitter, y antes en Facebook, y antes en…) un concepto de canales: yo ofrezco un canal público de clips de vídeo y un canal de apicultura (o no) y quien quiera seguirme puede optar entre seguirme a mí entero, seguir sólo el canal de apicultura, el de apicultura y el de historia del arte del siglo XVII, o cualquier otra combinación de canales…

El concepto, aunque bonito (o al menos eso me parece a mí) es difícil de implementar, primero, y de usar bien después: el día que monte el canal-cesar-fotografía-de-viajes, ¿cómo informo yo a los posibles interesados de forma efectiva pero sin que todo esto acabe en un aumento del ‘information overload’ que ya padecemos todos?

Difícil, sí, pero si en algún momento se puede implementar la idea (que no puede ser muy original) es en el nacimiento de una nueva red social. Voy a tocar madera un rato :-).

Mitchell Baker: Construir la infraestructura de la sociedad civil en línea

La única entrada de obm es un vídeo de la charla de Mitchell Baker hace unos días en el reciente Personal Democracy Forum. Creo que enlaza bien con la entrevista que le hice para Mosaic, que los amplía y que toca unos cuantos puntos muyy interesantes sobre democracia y tecnología, en estos tiempos que corren.

Para aquellos para los que el inglés no sea lengua grata, añado aquí abajo mi traducción de la charla. Siempre es mejor ir a la fuente, pero he pensado que a algunos os podría ser útil…

Watch live streaming video from pdf2011 at livestream.com

Continuar leyendo «Mitchell Baker: Construir la infraestructura de la sociedad civil en línea»

El Financial Times, intentando saltarse el ‘peaje iTunes’

Interesante movimiento del Financial Times (aunque poco sorprendente: tenía que llegar el momento en que alguien lo intentase). Cuentan en TechCrunch que acaban de lanzar «aplicación» con modelo de suscripción de contenidos, pero que la app, efectivamente, va entre comillas.

Ya hace meses que Apple anunció su modelo para ofrecer aplicaciones con contenidos de pago en iTunes: una comisión del 30% (que no es tan exagerada: los quiosqueros también se quedan con su pedazo de la tarta, no lo olvidemos, a cambio de ser el servicio de distribución y relación con el cliente) y el control absoluto de la relación con el cliente (el productor de contenidos no tiene acceso a ninguna información sobre el suscriptor).

Mientras tanto, los navegadores de iOS, Android y el resto de sistemas operativos para dispositivos móviles se han ido volviendo cada vez más potentes en el soporte de las características que uno querría usar en una ‘app’ móvil: un paseo por caniuse.com basta para comprobar que los WebKits de Android y iOS soportan, por ejemplo, Web Storage, bases de datos Sqlite (aunque todavía no IndexedDB), datasets y hasta @font-face (parcialmente en Android, pero todo llegará). Podemos suponer, además, que los contenidos de las aplicaciones nativas estarán en algo muy parecido a HTML y CSS, si quien sea tiene alguna esperanza de servirlo a múltiples plataformas…

Si sumamos las características que no gustan en los medios del modelo iTunes con las que sí les gustan de HTML5 en el navegador móvil, la conclusión era sencilla: desde ya el Financial Times ofrece un app.ft.com. Al visitar esa página desde el navegador nativo de iOS la ‘landing page‘ guía al usuario para añadir la ‘app’ a la pantalla inicial del dispositivo e intenta hacerse un lugar de pleno derecho en ese espacio, utilizando la web para ofrecer contenidos de pago y gratuitos al lector, sin [tanta] intermediación de los de la manzana.

Nadie puede prever si la cosa tendrá éxito: ahorrarse el 30% de la comisión no es despreciable, pero también es muy cierto que, a cambio, en el FT desprecian la ‘labor del quiosquero’ y por tanto dejan de contar con la ayuda del que probablemente sea, a día de hoy, el mejor escaparate del mundo. A lo mejor dentro de un año navegamos por un mar de subdomios app.loquesea.com, a lo mejor el FT lanza una app nativa para iOS dentro de tres meses.

En cualquier caso, habrá que estar atentos…

¿Opina Adobe que las revistas digitales se maquetarán en InDesign?

No me gustaría a mí ser el encargado de tomar las decisiones en Adobe por lo que respecta a plataformas de edición y publicación de revistas digitales. Estoy convencido de que, como mínimo, los ‘product managers‘ de Acrobat, InDesign, Dreamweaver y Fireworks reclaman el espacio como propio, y no hay suficiente balón como para repartir juego entre cuatro galácticos de semejante magnitud. Y si sólo con eso el problema ya sería mayúsculo, por poco seso que tenga, quien sea tendrá, además, que preocuparse por si hay en realidad suficiente mercado o se trata todo de un enorme ‘hype‘ y acabaremos publicando PDFs ‘de los de toda la vida’, sin interactividad ni inventos extraños de paginación/navegación (llámenme carca, pero yo sigo pensando que, con todas sus limitaciones, ese es el modelo más viable, como mínimo a corto y medio plazo).

En cualquier caso, la cuenta de resultados actual no se nutre de reflexión y algo hay que vender a Condé Nast y el resto de grandes editores. Y, como mínimo a ese mercado, Adobe hace tiempo que le está vendiendo la moto de que el ‘product manager’ que manda es el de InDesign (algo me dice que ayuda el hecho de que en las grandes revistas esa es la herramienta que quieren ver, porque esa es la herramienta que están usando y no hay fuerza más poderosa que la inercia). Las versiones iPad de las revistas de Condé Nast se han desarrollado, hasta ahora, en colaboración directa con el fabricante de software, intentando obtener una solución que Adobe pueda vender y que permita al grupo editorial mantener su posición y ser el primero en plantar una pica en este Flandes digital que se adivina tan potencialmente lucrativo.

En esa línea, el canal RSS de los ‘laboratorios’ de Adobe comunicaba ayer a última hora que la fase de ‘preview pública’ de la Adobe Digital Publishing Suite se cerraba… y dicha ‘suite’ pasa a ser un producto oficial y de pleno derecho del catálogo. Con página oficial y todo, naturalmente, en la que encontraréis la [poca] información adicional que dan. No es la ADPS un producto para el consumidor. Ni, presumiblemente, para el ‘prosumer’: el producto se ofrece en versiones ‘Professional’ y ‘Enterprise’ y para obtener un precio hay que hablar con un representante de la casa. Dudo mucho que se lo pueda permitir alguien que no esté ganando ya dinero en el sector editorial.

Volviendo al título de la entrada, lo único que podemos sacar en claro de todo esto es que, de momento, en Adobe gana el señor InDesign, puesto que la parte software de ADPS es una especie de plug-in (Folio Producer) que funciona sobre dicha herramienta. La parte potente de ADPS, en cualquier caso, es la de los servicios que ofrece Adobe a los editores: en primer lugar un ‘producer’ que tomará esos ‘folios’ creados con InDesign más el plugin y los preparará para los múltiples formatos de salida previsibles/previstos, después un servicio de distribución hacia las diferentes plataformas, a continuación servicios de comercio electrónico y analítica para poder monetizar y, finalmente, para los editores más potentes, un ‘viewer builder service’ para (o al menos eso es lo que leo yo) acabar de personalizar la experiencia de usuario del lector a la medida de lo que desee la publicación.

Mi [modesta y poco informada] opinión al respecto es que la vía InDesign no es el futuro en un universo de múltiples resoluciones y tasas de aspecto: quien produce está acostumbrado a un mundo de absolutos (el del papel) y hay un gran valor en ser continuista con las herramientas, pero la cosa que quieren producir se parece, más que a ninguna otra, a una web muy sofisticada y no puedo evitar pensar que ese campo lo acabarán ocupando los diseñadores web que, haberlos haylos, ya han aprendido a lidiar con un mundo en que todo es relativo, a aceptar las limitaciones del medio y a aprovechar las potencialidades de la interactividad. Y que en Adobe la ‘facción Dreamweaver’ sigue trabajando con ello en mente (véase, en los mismos Labs de Adobe, el prototipo de CSS Regions presentado también recientemente). Pero eso sólo es mi opinión… y sólo el tiempo decidirá quién acierta y con qué herramientas acabaremos jugando.